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Preface 

The  Defense  Advanced  Research  Projects  Agency  (ARPA)  and  the  Navy  are 
presently  sponsoring  the  development  of  interactive  message  processing  services  which 
are  to  provide  the  basis  for  a  test  of  automated  military  message  processing  on  Oahu  in 
1977.  Prior  to  the  experimental  use  of  these  services,  information  has  been  gathered  as 
design  inputs  so  that  the  resulting  test  services  may  more  accurately  reflect  the  needs 
and  wants  of  the  potential  user  community. 

This  report  (sponsored  by  ARPA)  presents  findings  of  such  an  information-gathering 
exercise:  a  study  of  triservice  personnel  in  Operations  at  CINCPAC  Headquarters,  Camp 
Smith,  Oahu.  The  objective  of  the  study  was  to  identify  necessary  and  desirable  message 
processing  functions,  along  with  their  syntactic  representation  and  vocabulary.  The 
functions  so  identified  are  enumerated  here,  along  with  the  probable  utility  of  each,  as 
judged  by  the  military  personnel  participating  in  the  study.  In  addition  to  this  input  from 
potential  users,  the  authors  recommend  various  alternative  implementation  practices  for 
m^ny  of_the  functional  features.  ’  Crr<\p*J£» 

The  primary  readership  of  this  paper  includes  those  persons  designing  and 
implementing  test  services  at  BBN,  MIT,  and  USC/ISI,  along  with  their  clients  ARPA  and 
NAVELEX.  The  report  is  also  intended  for  Operations  personnel  at  CINCPAC,  for  their 
review  and  comment.  The  report  is  not  intended  for  the  uninitiated,  hence  much  jargon 
(military  and  computer  science)  is  used. 
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A  Note  to  the  Reader 

A  summary  usually  summarizes  a  report,  giving  its  major  conclusions,  impact,  and  so 
forth.  Because  this  report  has  limited  distribution,  we  see  its  primary  value  as  an  input,  a 
collection  of  weighted  suggestions,  to  the  three  groups  designing  candidate  test  services. 
Such  individuals  need  not  a  summary,  but  rather  the  details.  We  have  shortened  the 
report  where  possible,  trying  not  to  lose  the  essence  of  the  collective  military  attitude 
toward  each  potential  service  feature. 

An  important  part  of  the  readership  will  not,  however,  actually  be  designing  the  test 
service.  Rather  than  provide  a  separate  summary  for  them,  we  provide  the  following 
advice:  Read  Chapter  1  (introduction)  and  Chapter  16  (conclusions).  If  a  few  more 
specifics  are  desired,  scan  the  table  of  contents  for  material  of  interest.  The  last  section 
of  most  chapters  contains  our  interpretations  and  recommendations. 


-\  v.  •.  • 


■V  .  .  «  IV.  w 
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1.  INTRODUCTION 


1.1  BACKGROUND  AND  PURPOSE  OF  THE  STUDY 

This  paper  reports  the  results  of  a  recent  survey  research  study,  employing 
triservice  military  operations  personnel,  conducted  to  gather  information  helpful  in 
designing  a  user-oriented,  automated  message  service.  It  was  carried  Out  during  July, 
1976.  Methods  used  in  the  study  were  based  in  part  on  earlier  research  done  by  one  of 
the  authors  [Heafner  75]  [Heafner  76],  and  in  part  based  on  conventional  survey  research 
methods.  The  results  obtained  are  reported  here  to  facilitate  the  definition  of  a 
computerized  message  service  that  is  most  sutable  for  the  majority  of  operations 
personnel  in  administration  and  in  command  and  control.  Specifically,  this  study,  in 
conjunction  with  an  earlier  companion  paper  [Heafner  76],  is  part  of  a  larger,  ongoing  test 
program.  It  is  planned  to  help  develop  a  natural  and  sufficient  man-computer  language 
and  to  accurately  determine  adequate  functional  processing  needs. 

The  paper  is  intended  as  a  working  document  for  those  fabricating  the  test  services, 
and  for  those  responsible  for  the  overall  test  management.  The  main  thrust  of  the  study 
is  to  identify  needed  message  sei  vice  functions.  The  results  also  supplement  the 
companion  report  in  terms  of  language  constructs  for  message  operations. 


1.2  SUBJECTS  OF  THE  STUDY 

Twenty-four  subjects  were  interviewed  in  depth.  They  were  chosen  by  CINCPAC 
randomly  within  a  stratified  (i.e.,  J3  Operations)  sample  to  reflect  the  characteristics  of  a 
larger  population  of  potential  military  users.  For  purposes  of  analysis  and  reporting,  the 
subjects  are  placed  in  each  of  three  categories. 


CATEGORY  1:  J3  Operations  (i.e.,  all  subjects) 


SUBJECT  RANK  NO,  OF  SUBJECTS 


CAPT  1 

SSG  2 

TSG  2 

SFC  2 

LTCDR  6 

MAJ  1 

CDR  4 

RFC  1 

YN1  2 

MSG  1 

COL  1 

LTCOL  1 


CATEGORY  2 


SUBJECT  DESCRIPTION 

NO,  OF  SUBJECTS 

Enlisted  personnel,  message  distribution 

3 

Enlisted  personnel,  action  officer  support 

7 

Action  officers 

13 

Senior  officer 

1 

CATEGORY  3 


SUBJECT  DESCRIPTION 


NO.  OF  SUBJECTS 


Enlisted  personnel 
Officers 


10 

14 


Although  our  recommendations  and  conclusions  are  based  on  24  subjects,  the 
statistics  represent  only  22.  Two  subjects  were  interviewed  together,  at  their  request. 
This  violated  a  situation  variable  which  we  wished  to  control.  Consequently,  their 
responses  are  not  considered  in  the  statistics.  However,  their  responses  are  indeed 
considered  in  our  recommendations  and  their  dialogues  appear  in  the  report. 


1.3  FORMAT  OF  THE  STUDY 

The  study  began  with  introductory  remarks  by  the  interviewers  to  provide  a  setting 
for  the  question/answer  portion  which  followed.  The  setting  is  best  described  by 
including  here  the  notes  used  as  introductory  remarks.  They  follow  in  italics. 

We’re  from  the  University  of  Southern  California  and  u/e  are  working  with  the 
Advanced  Research  Projects  Agency  in  Washington  and  military  communications  people 
both  here  and  m  Washington,  to  develop  an  automated  message  service.  The  message 
service  that  we  are  planning  is  a  completely  automated  writer-to-reader  service 
incorporating  message  composition,  transmission,  receipt  and  archival.  This  service  will  be 
installed  here  for  a  test  throughout  1977. 

The  reason  we  have  asked  you  to  help  us  is  that  we  want  to  find  out  how  you 
process  messages,  and  determine  what  styles  of  communication  you  would  like  for  a 
computerized  service,  that  is,  what  kind  of  features  would  be  necessary,  how  you  would  like 
to  instruct  the  computer  set.  -e  to  carry  them  out,  and  what  vocabulary  words  seem 
natural  and  convenient  to  you.  We  believe  that  we  can  build  a  much  more  useful  service  if 
you  and  others  who  actually  process  messages  will  help  us  design  the  service. 
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In  order  for  us  to  Learn  some  of  these  things  from  you,  we'd  Like  to  ask  you  some 
questions  and  get  your  opinions  on  some  of  the  tentative  plans  we  now  have  for  the 
service.  What  we  hope  to  Learn  from  these  questions  is  just  how  you  wouLd  like  to  process 
messages  automatic  ally.  So  feel  free  to  make  comments  at  any  time  as  we  go  along.  That 
is,  mention  anything  you  might  think  of  that  we've  omitted  or  anything  that  we're  doing 
wrong. 

Before  we  ask  the  questions,  let  me  go  through  a  scenario  that  illustrates  the  kind  of 
service  we  think  would  be  suitable  for  your  use  here.  The  reason  for  going  over  this 
scenario  is  to  provide  a  context  or  setting  for  the  questions,  so  that  you'll  understand  what 
we  think  we  know,  and  don't  know. 

The  scenario  illustrates  the  nature  of  message  handling  practices  using  an 
automated  service  and  it  is  based  on  conversations  with  military  communications  people  in 
Washington  and  here. 

The  user  logs  onto  the  service  in  the  morning  from  his  CRT  terminal  (Fig.  l-l ) 
located  in  or  near  his  office.  After  he  has  typed  his  identification,  the  service 
automatically  displays  excerpts  of  messages  awaiting  his  attention,  sort  of  a  table  of 
contents  (Fig.  1-2).  These  include  messages  for  his  information  or  action,  drafts  for  his 
review  and  chop,  incompleted  drafts  which  he  is  composing,  and  so  forth.  This  display  of 
excerpts  of  messages  and  drafts  we  call  his  PENDING  file. 

Let  us  suppose  he  wishes  to  read  a  particular  incoming  message.  Since  each  excerpt 
is  numbered,  he  indicates  his  desire  to  see  the  message  merely  by  pressing  a  button  on  his 
keyboard  marked  DISPLAY  and  then  typing  the  number  which  is  adjacent  to  the  desired 
message.  This  causes  the  message  to  be  displayed  on  his  screen  (Figs.  I -3a,  l-3b\ 
Although  the  entire  message  may  not  fit  on  the  screen  at  one  time,  by  pushing  scroll  up  or 
scroll  down  keys,  the  user  may  scan  all  of  the  message. 

If  he  feels  he  will  want  to  refer  to  this  message  again,  or  if  it  is  relevant  to  other 
messages  of  interest  over  some  period  of  time,  he  may  file  the  message  m  one  of  his 
personal  files.  For  example,  it  may  be  of  interest  to  him,  say,  in  terms  of  its  originator,  a 
location  to  which  it  applies,  and  a  type  of  equipnient  that  is  described  m  the  message's 
body.  He  tells  the  service  by  pressing  the  FILE  button  that  he  wishes  to  file  the  message  in 
other  than  in  his  PENDING  file.  He  types  the  name  of  the  personal  file,  along  with  the 
location  and  the  equipment  type,  as  keywords  for  retrieval.  He  may  later  recall  the 
message  by  naming  the  file  and  any  of  the  appropriate  keywords  or  the  originator  of  the 
message. 

One  special  form  of  file,  a  readboard,  provides  read  access  for  a  group  of 
mdividuab.  Since  the  readboard  is  always  maintained  inside  the  computer,  many  users 
may  access  that  board  simultaneously. 

A  user  may  wish  to  forward  a  message  to  some  other  user  m  the  organization  for  his 
attention  or  action.  Two  keys  allow  the  user  to  forward  a  message  for  action  or  for 
information.  The  distribution  field  of  the  message  is  automatically  updated  to  reflect  this 
additional  distribution  information. 


» 


l 


File:  PENDING 

I.  Secret  Immediate  Action  200I46Z  July  76  NAVSEEACT  Korean  Operations 
7.  Unclass.  Routine  Info.  I92723Z  July  76  CINCPACFIT  Korean  Operations 
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Perhaps  prior  to  forwarding  or  filing  a  message,  the  user  would  like  to  add  a  note, 
either  to  the  message  or  the  file  in  which  the  message  is  to  be  placed.  The  service  allows 
the  user  to  specify  where  such  a  comment  should  go  and  who  is  allowed  to  see  it,  in  case  it 
is  not  a  public  statement. 

He  may  also  wish  to  respond  to  an  incoming  message.  If  he  wishes  to  get 
hardcopies  of  those  messages  referenced  in  the  displayed  message,  he  presses  the  buttons 
labeled  HARDCOPY  and  REFERENCES.  Perhaps  there  are  other  data  or  messages  which  he 
has  in  a  personal  file  which  he  feels  are  needed  for  reference  in  responding  to  this 
message.  Again,  he  uses  the  display  button  and  types  the  file  name  along  with  any 
specific  qualifiers  that  identify  the  messages  of  interest.  For  example,  he  might  type 
" from  CINCPACFLT."  Those  messages  that  he  has  selected  are  excerpted  and  displayed.  If 
he  wants  a  hardcopy  of  a  particular  message  for  reference,  he  presses  HARDCOPY  and 
types  the  number  adjacent  to  the  message  excerpt. 

Suppose  he  has  composed  the  reply  using  pencil  and  paper  and  given  it  to  his 
secretary.  To  enter  the  new  draft  on-line,  using  her  terminal,  the  secretary  presses  the 
DRAFT  button.  A  blank  message  form  is  displayed.  With  button  controls  and  keyboard, 
she  enters  and  edits  the  draft.  She  enters  the  codes  for  offices  who  should  review  the 
message  prior  to  release.  Parallel  and  serial  routing  to  reviewers  are  indicated  by  the  use 
of  separate  lines. 

Let  us  return  to  the  user  who  is  presently  reviewing,  on-line,  a  draft  message  he  has 
received  for  chop.  Suppose  other  traffic  arrives  while  he  is  reading  this  draft.  He  is 
alerted  to  this  fact  by  an  informative  notice  appearing  in  a  special  area  or  "window"  at  the 
top  of  his  display.  He  may  chose  to  preeempt  his  current  activity  and  deal  with  the  new 
message  immediately,  or  he  may  decide  to  continue  with  the  present  work  and  handle  the 
new  traffic  later.  This  time,  he  chooses  the  latter.  He  finishes  reading  the  current 
message  and  approves  it.  He  indicates  his  approval  by  pressing  the  CHOP  button.  When 
he  has  taken  this  final  action  on  the  draft,  his  PENDING  file  excerpts  are  again 
automatically  displayed.  The  message  to  which  he  was  earlier  alerted,  and  chose  to  ignore . 
is  now  excerpted  and  specially  marked  to  indicate  its  newness  of  arrival. 

Perhaps  the  newly  arriving  message  was  a  draft  of  his  own,  returning  from  chop  for 
redraft.  In  this  case,  the  alert  indicates  this.  Using  the  DISPLAY  button,  he  may  ask  to 
see  the  simultaneous  display  (on  different  areas  of  the  screen)  of  both  his  original  version 
and  the  edited  version  which  was  reviewed.  With  control  buttons  he  may  scroll  the  message 
to  examine  the  parts  of  interest.  Let  us  assume  that  proposed  modifications  are  minor, 
and  since  it  is  not  necessary  to  retype  the  entire  message  he  makes  the  corrections  himself. 
He  then  sends  it  back  for  chop,  using  the  SEND  FOR  CHOP  button. 

This  scenario  should  give  you  some  idea  of  our  thinking.  Now,  we  want  to  ask  some 
questions  to  determine  how  we  can  modify  this  service  for  your  use.  We  have  two  kinds  of 
questions.  One  kind  is  a  closed-ended  question  where  we  simply  want  you  to  comment  on 
certain  proposed  features  of  the  message  service.  We  want  you  to  tell  us  if  the  feature  is 
really  good  or  really  bad  or  somewhere  in  between.  We  would  like  for  you  to  use  this 
scoring  scale  to  rate  features  of  the  service  (Fig.  1-4).  (The  scoring  scale  was  explained 
at  this  point.)  The  other  kind  of  question  is  a  discussion  question  where  we  want  to 
determine  your  requirements  and  desires,  and  here,  we  wish  to  learn  more  about  your 
current  procedures. 
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It  is  a  necessary  requirement. 

It  is  highly  desirable  and  useful. 

It  is  useful  ond  desirable. 

It  is  acceptable. 

It  is  not  useful  nor  desirable. 

It  is  highly  undesirable  and  not  useful. 

It  is  in  conflict  with  requirements  or  procedures. 


Fig.  1-4  Rating  Scale  for  Features  of  the  Service 


Subjects  were  asked  both  closed-ended  and  open-ended  questions.  In  the  case  of 
closed-ended  questions,  each  respondent  was  asked  to  numerically  rate  or  score  various 
message  service  features  on  the  scale  shown  in  Fig.  1-4.  These  were  not  completely 
closed-ended  questions  in  that  the  respondents  usually  amplified  and  justified  their 
ratings.  With  open-ended  questions,  the  respondents  were  asked  to  discuss  or  elaborate 
some  current  procedure  or  organizational  concept.  These  generally  led  to  a  short 
dialogue  or  discussion  between  the  respondent  and  the  interviewers. 

1.4  THE  FORMAT  OF  THE  REPORT 

The  format  of  chapters  3  and  5  through  15  is  as  follows.  The  first  section  provides 
an  explanation  to  the  reader  of  the  nature  and  intent  of  the  questions  in  that  chapter. 
The  questions  and  answers  follow.  For  each,  a  narrative  is  given,  in  “italics"  as  it  was 
presented  to  the  respondents.  (The  questions  as  they  appear  in  these  chapters  were 
actually  taken  from  one  of  the  taped  sessions.)  Next,  a  statistical  summary  of  that  question 
is  given,  followed  by  samples  of  dialogue  between  the  respondents  and  the  interviewers, 
substantiating  the  statistical  results.  At  the  end  of  each  chapter,  the  authors’ 
interpretations  and  recommendations  are  stated.  In  many  cases,  we  give  two 
recommendations:  that  considered  essential,  and  a  more  elaborate  facility  deemed  useful. 

And  now,  a  bit  more  about  the  statistics  appearing  in  most  chapters.  The  statistics 
reported  for  each  of  the  rating  questions  are  the  mean,  the  mode  and  the  standard 
deviation.  The  meanings  and  interpretations  of  these  statistics  are  best  described  in 
reference  to  one  of  the  questions  asked  each  subject.  Figure  1-5  represents  the 
distribution  of  answers  to  the  following  question: 

In  your  particular  job  function  you  may  usually  look  at  certain  parts  of  the  message  first 
and  then  look  at  other  parts  of  lesser  interest  later.  So,  one  facility  that  we  could  provide 
is  to  allow  you  to  specify  the  parts  you  want  to  see  first.  Then  we  would  rearrange  the 
parts  of  every  message  for  you,  so  that  every  time  you  ask  to  display  a  message  it  would 
appear  in  the  format  you  want,  rather  than  the  standard  DD-173  format.  Would  that  be 
useful  or  not  useful  to  you? 

For  each  of  the  possible  response  ratings  (-3  to  +3),  the  number  of  respondents 
actually  giving  that  rating  is  diagrammed.  That  is,  one  person  gave  a  rating  of  -3,  three 
persons  said  -1,  and  so  on,  up  to  three  persons  rating  the  feature  +3,  as  shown  in 
Fig.  1-5.  The  Mean  is  just  the  average  of  all  the  responses.  The  Mode  is  the  answer 
most  frequently  given.  It  is  the  rating  corresponding  to  the  "high  point"  of  the  frequency 
distribution.  As  such,  it  is  a  very  important  statistic  where  the  data  represents  attitude 
responses  of  people.  The  Standard  Deviation  represents  the  spread  of  the  scores. 
Approximately  two  thirds  of  all  respondents  answered  within  plus  or  minus  the  standard 
deviation  (about  1.6  in  our  example)  of  the  mean  (about  0.7  in  our  example).  A  large 
standard  deviation  represents  responses  which  are  quite  spread  out.  There  would  be  a 
greater  diversity  of  opinion  on  the  particular  question.  A  small  standard  deviation, 
conversely,  represents  a  greater  uniformity  of  opinion  on  the  particular  question.  It  is  the 
authors’  opinion  that  these  three  statistics,  coupled  with  the  frequency  distribution  graphs, 
provide  a  useful  guide  in  determining  the  relative  importance  and  utility  to  the  test 
subjects  of  a  particular  service  feature. 


15 


-3.  iMnWriW  (  1) 

I 

1 

I 

- 1 .  VnViWiMi'nWoVVoVVnVi'nV  (  3 ) 

I 

1 

I 

0 .  irtlftirirfrtcirttfiici'rtritirirfrfrici'tirltirtricft  ( 

I 

I 

I 

1  •  Vrff**VhWnViV**VhV*Tfr**friV>V'ftVf****  ( 

I 

1 

I 

2 .  VnVrt  VrihYft YnYVriirrt* Yn'n’f  (  3 ) 

1 

I 

I 

3.  YoYYnVYnVYnVYnVYnVYnVAVir  (  3) 

1 

I 

I 

I 

I . I . I . 

0  2  4 

frequency 


MEAN 


0.700 


0.000 


STD  DEV 


1.559 


VALID  CASES 


HISSING  CASES 


Fig.  1-5  Ratings  for  Field  Reordering  Capability 


It  was  indicated  above  in  the  description  of  the  subjects  of  this  study  that  subjects 
represent  enlistee*  personnel  in  administration,  enlisted  personnel  supporting  action 
officers,  and  officers.  In  some  cases  the  mean  response  of  one  group  of  subjects  to  a 
question  was  different  from  the  response  of  another  group.  For  those  questions  to  which 
there  was  a  significant  response  difference,  the  frequency  diagrams  and  statistics  for  the 
contrasting  groups  are  presented.  This  information  is  of  use  to  system  designers  because 
it  breaks  apart  the  response  to  a  particular  question  and  makes  it  possible  to  identify  a 
subgroup  of  respondents  for  whom  a  particular  function  or  feature  is  particularly 
desirable  or  particularly  undesirable. 


2.  MESSAGE  HANDLING  PRACTICES  OF  J3  OPERATIONS 


Before  we  examine  the  remarks  of  J3  personnel  in  detail,  it  might  be  helpful  to  some 
readers  to  succinctly  portray  some  of  the  more  prominent  job  functions  affected  by  the 
1977  message  processing  experiment.  Interviewed  were  both  officers  and  nonofficers  in 
J3  Operations  whose  duties  spanned  administration,  command  watch,  and  action  officer’s 
functions. 

With  respect  to  the  test  service,  the  administration  personnel  are  tasked  with  two 
main  responsibilities.  One  responsibility  is  to  assign  action  for  incoming  messages  in  two 
ways.  When  they  are  familiar  with  the  subject  matter,  they  assign  the  action  directly  for 
the  appropriate  directorate.  If  the  subject  is  unfamiliar,  they  use  a  card  catalog  indexed 
on  subject  to  compare  with  the  subject  of  the  message.  For  each  subject  entry  in  the 
catalog,  a  distribution  list  is  appended,  showing  primary  responsibility  for  that  subject 
matter. 


Respondent:  We  go  by  subject  of  the  message.  We  have  a  card  file  by 
subject  which  shows  who  is  action  and  who  is  info.  If  it  is  a  subject  we 
handle  every  day  and  we  are  familiar  with  it,  then  we  automatically  know 
where  to  assign  it,  but  if  it  is  not  familiar  then  we  look  on  the  card  file. 

Respondent:  We  stamp  it  ACTION  and  put  it  in  his  box,  he  comes  by  and  picks 
it  up  about  every  two  hours. 

In  terms  of  routing  and  action  assignment,  an  associated  service  provided  by 
administration  helps  complete  paper  work  for  rerouting  misdirected  messages. 


Respondent:  I  just  send  it  back  down  to  the  admin  section  and  tell  them  it  is 
not  for  me  and  who  I  think  it  should  be  for. 

Respondent:  I  call  down  to  301  and  give  them  the  date-time  group  and  the 
originator.  That’s  all  they  need.  "That’s  been  sold,  transfer  to  J— .”  They 
make  out  the  paper  work.  Then  that  message  will  come  out  of  the  computer 
again,  sometime  later,  showing  this  change. 

The  second  major  service  provided  for  the  other  directorates  by  administration  is  to 
maintain  all  messages,  incoming  and  outgoing  for  some  time  for  purposes  of  later  retrieval. 
Much  of  their  time  is  spent  in  such  message  retrieval. 


Respondent:  For  example,  we’ll  get  a  call  from  -  wanting  a  SPECAT 

message,  and  the  only  thing  he  will  know  is  the  approximate  date-time  group 
(month  or  week)  and  from  Admiral  so-and-so.  So,  we’ll  have  to  review  every 
SPECAT  message. 

The  command  watch  team,  manned  24  hours  a  day,  must  be  immediately  responsive 
to  incoming  traffic. 


Respondent:  We  get  every  immediate  and  flash  message  at  the  same  time  the 
comm  center  gets  it.  The  reason  the  command  center  exists  is  to  act  on 
messages  as  they  come  in.  A  perfect  example  was  the  Mayaguez.  We  got 
the  first  flash  critics,  and  within  minutes  we  had  people  in  action. 

After  normal  working  hours,  they  provide  backup  for  staff  agencies. 

Respondent:  For  J4  messages  of  immediate  or  flash  that  arrive  after  hours,  we 
call  them  from  the  command  center.  If  it  is  immediate  or  flash,  right  down  at 
the  bottom  it  says  "notified  at."  We  enter  there  who  we  call  and  the  time. 

Also,  the  command  watch  team  constructs  readboards  for  morning  review. 

Respondent:  I  make  up  General - ’s  readboard  from  1500  in  the  afternoon 

until  6:00  in  the  morning. 

The  action  officers  are  both  recipients  and  originators  of  message  traffic. 


Respondent:  When  you  deal  with  JCS,  they  task  you  with  a  particular  item  and 
then  you  in  turn  go  out  to  your  subunified  commands.  They  respond  to  you, 
and  you  in  turn  go  back  to  XS  to  terminate  the  project.  So  you’re 
generating  all  the  inputs  from  PACFLT  and  PACOM  to  respond.  You  could 
terminate  it  by  going  directly  back  to  XS  if  you  had  the  current  data  to 
answer  them.  But  if  you  have  to  go  out  into  the  PACOM  to  get  it,  you  could 
generate  up  to  150  messages. 

Messages  are  closely  intertwined  with  other  forms  of  correspondence  and 
documentation,  vital  to  the  functioning  of  these  action  officers. 


Respondent:  There  are  a  number  of  documents  that  we  use,  that  are  XS 
documents,  DIA  appraisals,  reports,  things  of  this  nature  —  things  other  than 
messages,  which  I  presume  want  to  be  in  the  system. 

Respondent:  My  files  are  not  strictly  messages.  They  contain  survey  reports, 
inputs  by  mail,  memos,  and  so  forth.  So,  these  are  some  of  the  things  that 
could  be  looked  at.  They  are  all  part  of  preparing  messages. 


3.  MESSAGE  FORMATTING  AND  HIGHLIGHTING 


In  planning  an  on-line,  interactive  service  for  any  application,  one  tries  to  use  to 
advantage  those  features  inherent  in  an  interactive  facility.  One  such  feature  is  the 
ability  to  quickly  reconfigure  information,  for  display,  in  a  variety  of  ways.  This  general 
notion  gives  rise  to  particular  questions  about  formatting  the  basic  unit  of  information  in 
this  service  —  the  message.  Would  it  be  advantageous  for  a  user  to  determine  the 
arrangement  of  messages  displayed  to  him?  Specifically,  would  he  like  to  be  able  to  specify 
the  order  in  which  the  various  parts  of  the  message  appear  when  displayed?  Furthermore, 
in  regard  to  the  message’s  appearance,  would  it  not  be  useful,  in  terms  of  reducing  a 
cluttered  appearance,  for  him  to  be  able  to  visually  suppress  parts  of  the  message  that 
are  generally  of  little  or  no  interest  to  him?  How  should  this  suppression  be  controlled? 

User  control  over  the  presentation  of  a  message  is  the  subject  of  this  chapter. 
Because  the  message  is  logically  divided  into  parts,  because  the  electronic  manipulation  of 
text  is  rather  fast  and  straightforward,  and  because  there  may  be  large  individual 
differences  in  user’s  opinions  as  to  how  they  would  prefer  to  see  a  message,  information 
was  gathered  relative  to  the  above  questions. 


3.1  REORDERING  PARTS  OF  THE  MESSAGE 


3.1.1  The  Question  of  Reordering 

The  first  few  questions  deal  with  the  form  or  appearance  or  format  of  a  message. 
In  your  particular  job  function  you  may  usually  look  at  certain  parts  of  the  message  first 
and  then  look  at  other  parts  of  lesser  interest  later.  So,  one  facility  that  we  could  provide 
is  to  allow  you  to  specify  the  parts  you  want  to  see  first.  Then  we  would  rearrange  the 
parts  of  every  message  for  you,  so  that  every  time  you  ask  to  display  a  message  it  would 
appear  in  the  format  you  want,  rather  than  the  standard  format.  Would  that  be  useful  or 
not  useful  to  you? 


3.1.2  Analysis  of  Responses  to  Reordering 

Considering  all  subjects,  reordering  rales  only  acceptable,  with  a  mean  =  0.7,  std. 
dev.  =  1.6,  and  mode  =  0.  There  were  two  significant  differences  when  the  means  of 
subgroups  were  compared.  The  differences  in  responses  between  enlisted  personnel  (Fig. 
3-1)  and  officers  (Fig.  3-2)  were  significant.  The  enlisted  personnel  rated  reordering  as 
desirable.  Even  more  significant  was  the  differences  in  responses  between  enlisted 
personnel  in  administration  and  action  officers.  Enlisted  men  in  administration  rated 
reordering  highly  desirable  while  action  officers  rated  it  acceptable. 
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3.1.3  Remarks  Supporting  Field  Reordering 


Respondent:  It  is  somewhat  useful. 


Respondent:  I  would  like  to  see  the  subject  line  first. 

It  is  the  authors’  impression  that  these  respondents  wished  to  see  the  subject  in 
order  to  perhaps  postpone  reading  the  body  of  the  message  until  a  more  convenient  time. 
Alerting  had  not  been  discussed  at  this  time.  The  following  respondent  (who  rated  both 
reordering  and  suppression  as  zeros)  states  the  equivalent. 


Respondent:  ...  whereas,  if  you’re  expecting  a  reply,  perhaps  you  are  waiting 
for  something  from  a  component  in  order  to  make  up  a  package  to  go  to  a 
higher  headquarters,  you  might  be  looking  for  a  particular  subject  to  come  in. 
You’d  want  to  run  through,  perhaps,  your  PENDING  file,  looking  just  at 
subjects,  and  then  go  to  the  main  body  of  the  message. 


3.1.4  Remarks  Opposing  Field  Reordering 


Respondent:  It  is  difficult  for  me  to  believe  that  each  one  of  us  should  have 
our  own  specific  desires  on  how  a  message  should  be  sent  to  us.  Standard 
formatting,  I  think,  is  essential. 


Respondent:  It’s  awfully  hard  to  Kick  an  old  habit.  I  think  it  would  "blow  my 
mind”  to  see  something  all  turned  around. 


Respondent:  The  way  the  message  comes  in  now  is  the  appropriate  way.  It  is 
not  useful. 


Respondent:  I  don’t  think  there  would  be  any  variance  from  the  standard. 


Respondent:  The  only  part  that  is  of  minor  interest  and  could  be  omitted  on 
first  viewing  is  the  internal  distribution.  But  I  like  the  message  the  way  it’s 
displayed  here  (Fig.  1-3). 


3.2  VISUALLY  SUPPRESSING  PARTS  OF  THE  MESSAGE 


3.2.1  A  Question  on  Field  Suppression 

Another  similar  feature  that  u/e  could  provide  is  to  allow  you  to  visually  suppress 
certain  parts  of  the  message.  That  is,  in  order  to  reduce  the  cluttered  appearance  of  your 
display,  you  could  indicate  those  parts  that  are  not  normally  of  interest  to  you,  and  then 
they  would  only  be  shown  to  you  on  request.  How  would  you  rate  such  a  facility? 

3.2.2  Analysis  of  Responses  to  Field  Suppression 

By  and  large,  the  subjects  held  about  the  same  opinions  of  the  utility  of  visual 
suppression  as  they  did  about  the  utility  of  reordering.  The  group  as  a  whole  rated 
suppression  acceptable,  with  a  mean  =  0.4,  std.  dev.  =  1.0,  and  mode  =  0.  There  was  no 
significant  difference  among  the  subgroups. 

3.2.3  A  Question  on  Control  of  Field  Suppression 

Would  you  rather  ask  for  specific  parts  to  be  unsuppressed  and  displayed,  or  instead 
would  you  rather  ask  for  all  of  the  suppressed  parts  to  be  displayed  at  once? 

3.2.4  Analysis  of  Field  Suppression  Control 

Of  those  persons  favoring  suppression,  six  answered  the  questions  on  how  it  should 
operate.  Four  wanted  a  binary  switch  and  two  preferred  to  type  a  parameter  naming  a 
particular  field  to  be  unsuppressed. 
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3.2.5  Remarks  Opposing  Field  Suppression 


\r\ 


Respondent:  I  can’t  visualize  any  benefit  of  that  to  me. 


Respondent:  I  would  rather  see  the  whole  message. 


3.3  REMARKS  IN  SUPPORT  OF  HIGHLIGHTING  MESSAGE  PARTS 

Highlighting  message  parts  by  higher  intensity,  underscoring,  and  so  forth  was  not 
among  the  prepared  questions,  although  the  question  did  arise  several  times;  sometimes  it 
was  prompted  by  the  interviewer  and  sometimes  by  the  respondent.  In  every  instance, 
the  respondent  favored  the  ability  to  specify  highlighting. 

To  provide  context  for  the  following  dialogue,  the  subject  had  brought  with  him  to 
the  interview  a  stack  of  hardcopied  messages.  He  occasionally  scanned  them  to  locate  a 
particular  kind  in  order  to  make  a  point. 


Respondent:  I’ve  been  on  that  job  for  so  long  that  I  can  just  look  at  a  message 
and  tell  whether  or  not  it  is  going  to  be  of  any  interest  to  me. 

Interviewer:  What  parts  do  you  look  at? 

Respondent:  I  just  look  at  the  piece  of  paper.  About  807  of  the  messages  I 
can  do  away  with  because  I  know  what  a  FIBIS  report  looks  like,  and  I  know 
what  a  DIA  report  looks  'ike.  An  OPREP  1,2,  and  4  all  look  the  same.  I  can 
tell  a  CIA  report  at  a  glance. 

Interviewer:  Basically,  you  glance  at  the  total  form  and  you  know? 

Respondent:  Right.  As  I  look  at  this  message,  the  first  thing  I  look  at  is  right 
down  in  the  middle.  Because  it  was  a  standard  message  format  I  would  have 
to  read  it.  And  the  first  thing  I  read  was  the  subject  line.  So,  I  guess  that  is 
what  I  look  at  first. 

Interviewer:  It  is  the  subject  you  look  at  rather  than  SSIC  code  or  special 
handling? 

Respondent:  Right.  I’m  looking  at  a  FIBIS  report.  It’s  always  about  Phnom 
Penh  or  Saigon,  or  Cambodian  revolutionaries. 

Interviewer:  It  seems  that  most  of  your  messages  would  fit  on  the  CRT  as  a 
single  page. 

Respondent:  Right. 


Interviewer:  Since  you  are  looking  at  the  subject  line  in  most  cases,  would  it 
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be  of  any  value  to  highlight  that  subject  line  in  any  way?  By  inverse  video  or 
higher  intensity  or  something  like  that? 

Respondent:  That  might  be  a  good  idea. 

Interviewer:  Have  you  seen  inverse  video  or  different  levels  of  intensity? 

Respondent:  I  understand  the  different  levels  of  intensity. 

Interviewer:  With  inverse  video,  the  letters  are  white  on  a  dark  background 
which  is  just  opposite  of  the  normal  dark  letters  on  a  light  background.  So 
the  subject  line  would  be  just  opposite  of  the  remainder  of  the  message. 
This  is  just  another  way,  like  higher  intensity,  to  make  the  subject  line  more 
prominent. 

Respondent:  That  might  be  a  good  idea.  I  thought  about  it  last  night,  about 
what  I  examine.  And  when  I  do  have  to  look  at  something,  my  eyes  seem  to 
focus  on  the  first  line  of  text  or  the  subject  line.  Now  I’m  looking  at  what’s 
called  a  RAINFORM.  I  have  to  look  at  it  because  there  are  two  types  out  of 
all  the  many  types  that  we  get  (and  they  all  look  alike)  that  I  have  to  keep, 
and  that  I  route  to  someone  in  the  operation  department.  I  look  right  in  the 

middle  of  the  subject  line  and  I  see  the  word  — — .  If  it  says - or - 

then  I  keep  it. 

Interviewer:  Okay,  so  you’re  looking  at  flagwords  as  well  as  the  subject  line 
itself. 

Respondent:  Yes.  I  would  say  that  most  of  the  officers  who  work  at  that 
desk,  after  a  while,  are  doing  the  same  thing  I’m  doing. 

Interviewer:  So,  there  are  parts  of  that  line  such  as  SSIC  code  that  you  are 
not  interested  in.  You  look  at  the  subject  itself  and  the  flagwords.  You 
might  want  only  those  parts  highlighted? 

Respondent:  Yes.  But  in  any  case,  don’t  rearrange  anything. 


3.4  INTERPRETATIONS  AND  RECOMMENDATIONS 

A  correlation  analysis  showed  no  significant  relationship  between  the  ratings 
assigned  to  reordering  and  those  assigned  to  suppression.  This  indicates  a  lot  of 
individual  variation  in  preferences  for  message  formatting  aids.  It  is  thus  inappropriate  to 
simply  offer  the  users  a  collection  of  such  aids. 

Based  upon  the  large  number  of  "don’t  cares"  as  rated  for  reordering  (mode  »  0), 
and  rather  high  variation  (std.  dev.  =  1.6),  we  do  not  recommend  the  ability  to  reorder. 

Likewise,  suppression  in  the  context  of  our  question  is  not  recommended.  Most 
users  wanted  to  see  the  message  in  its  standard,  familiar  form.  However,  comments 
attached  to  specific  fields  of  draft  messages  were  deemed  useful  (see  Chapter  9).  If  the 
comment  feature  is  implemented,  then  we  recommend  providing  a  variation  of  the 
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suppression.  Field-specific  comments  change  the  appearance  of  the  message  from  its 
standard  form.  Thus,  we  recommend  a  binary  control  which  suppresses  all  or  none  of  the 
comments,  along  with  other  status-like  information  not  normally  appearing  on  the  present 
message  form. 

Unfortunately,  highlighting  was  not  investigated  with  all  subjecis.  Yet,  it  was 
discussed  with  more  than  half  the  subjects  and  each  had  a  favorable  reaction. 
Highlighting  is  recommended.  The  minimum  recommendation  is  to  provide  a  facility 
to  highlight  by  higher  intensity  or  inverse  video  those  parts  of  the  message  that  would 
include  originator,  subject,  and  flagwords.  (These  parts  were  most  frequently  identified 
by  the  respondents  as  the  parts  they  observe  first.)  We  suggest  instructions  to  turn  on 
ar.d  off  the  highlighting.  This  allows  those  users  who  do  not  wish  to  use  this  feature  to 
ignore  it.  The  effect  of  the  instruction  should  be  remembered  (i.e.,  recorded  in  a  user’s 
profile)  so  that  it  does  not  have  to  be  set  for  each  message  or  for  each  time  the  user  logs 
on.  We  also  support  a  more  elaborate  arrangement  in  which  users  can  name  the  message 
parts  to  which  highlighting  applies.  For  compatibility  with  other  recommended  forms,  we 
would  suggest  that  this  appear  as  an  editable  list  of  message  field  names. 
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4.  PRESENT  MESSAGE  FILING  SYSTEMS  OF  J3  OPERATIONS 

Some  military  messages  are  of  transient  interest,  others  have  more  lasting  value. 
Consequently,  many  messages  are  maintained  in  files  for  varying  amounts  of  time.  The 
organization  of,  and  access  to,  active  files  and  archived  files  are  extremely  important 
design  issues  in  any  automated  service.  Filing  and  retrieving  of  messages  and  other 
materials  constitutes  a  large  part  of  the  daily  activity  of  many  potential  users  of  the 
service.  Since  filing  and  retrieving  are  of  such  importance,  a  considerable  part  of  this 
study  addressed  file  system  issues,  as  wilt  be  seen  here  and  in  Chapters  5,  6,  and  8. 

To  get  a  general  feel  for  their  present  filing  schema,  we  asked  each  subject  to 
briefly  describe  his  current  filing  arrangement.  Their  responses  have  not  been  analyzed 
in  any  sense;  they  are  included  to  give  the  implementers  a  feeling  for  the  sizes  of  files 
and  the  variety  of  filing  needs.  A  summary  of  their  comments  follows. 

4.1  A  SUMMARY  OF  FILING  ARRANGEMENTS 


Respondent  1 

There  are  four  files,  viz.,  SPECAT,  Eyes  Only,  Classified,  and  Unclassified.  Each  file 
is  arranged  according  to  date-time  group. 


Respondent  2 

This  individual  was  mainly  concerned  with  a  SPECAT  file  in  which  messages  are  filed 
by  DTG  and  maintained  for  six  months. 


Respondent  3 

Four  files  are  maintained  by  DTG.  They  are  Action/Cog.,  Eyes  Only,  SPECAT,  and 
Outgoing.  Most  requests  for  file  copies  of  messages  come  in  by  DTG. 


Respondent  4 

Files  are  subject  oriented. 


Respondent  5 

Several  files  are  maintained  by  subject.  Within  each,  messages  are  filed 
chronologically  by  DTG. 


Respondent  6 


This  individual’s  remarks  are  quoted  below. 

Respondent:  For  my  personal  use,  that  (in  reference  to  the  general  file  system 
described  in  Chapter  6)  would  fit  very  well,  because  most  of  the  things  on  the 
watch  team  are  time-oriented.  Everything  is  very  quiet  for  two  days  and 
then  suddenly  something  springs  up,  a  problem  that  you  have  to  work.  So, 
you  would  be  using  the  system  you  described,  and  when  the  problem  was 
completed,  you  could  store  it  all  on  magnetic  tape.  On  the  watch  team,  that 
time  element  is  probably  different  from  a  staff  agency,  where  they  may  have 
a  longer  period  of  interest. 

Interviewer:  How  long  do  you  normally  work  on  a  problem? 

Respondent:  It  depends  on  the  problem.  A  good  example  is  the  earthquake  in 
New  Guinea.  The  earthquake  occurred  last  week.  We’ll  get  messages  that 
kind  of  follow  a  bell  curve.  Things  will  start  rolling  along.  Then,  if  they  ask 
for  aid,  messages  will  start  flying  around  and  there  will  be  airlift  and 
coordination  between  various  agencies  in  getting  the  supplies  and  the  airlift, 
and  you’ll  reach  a  peak  there  where  lots  of  traffic  is  going  back  and  forth. 
Then  it  will  start  tapering  off.  This  will  go  over  a  period  of  perhaps  two  Or 
three  weeks. 

Interviewer:  What  is  the  total  volume  of  traffic  in  that  period  of  time  on  a 
given  topic? 

Respondent:  For  example,  the  Guam  typhoon,  which  might  be  unusual  because 
of  the  extensive  damage  done,  we  had  just  a  tremendous  amount  of  traffic  on 
that. 

Interviewer:  Hundreds?  Thousands? 

Respondent:  In  the  hundreds.  I  had  four  folders  on  that.  I  personally  had  a 
file  of  four  or  five  hundred  messages  on  that. 

Interviewer:  You  said  that  was  not  quite  typical?  It  was  a  little  heavy? 

Respondent:  Most  of  the  problems  we  work  don’t  get  up  that  high. 

Interviewer:  You  mentioned  that  it  looked  like  a  bell-shaped  curve,  the  traffic 
density.  Was  that  just  a  guess  or  has  this  been  studied? 

Respondent:  That  is  just  an  observation.  You  get  a  build-up  to  the  problem,  a 
few  preliminary  messages  requesting  information.  Some  of  them  die  right 
there,  'f  it  does  continue,  if  it  is  a  problem  or  requires  action,  then  it  takes 
off.  And  then  at  the  end,  after  the  action  is  completed,  there  are  a  few 
clean-up  messages. 

Interviewer:  How  many  problems  do  you  have  active  at  any  one  time? 

Respondent:  Normally,  the  number  of  problems  are  not  more  than  two  or 
three.  But  1  wasn’t  here  back  when  Southeast  Asia  was  still  going.  Right 


now  we  have  two  things  going  in  there.  Sometimes  everything  happens  at 
once. 

Interviewer:  Is  there  usually  one  problem  rising  as  another  is  tapering  off,  so 
that  your  work  load  is  relatively  constant? 

Respondent:  No,  usually  it  goes  in  spurts.  Just  going  back  to  the  Guam 
typhoon,  I  had  six  files  of  messages.  For  example,  one  was  just  the  wind 
warnings  put  out  by  the  weather  service  —  where  is  the  typhoon  now  and 
what  are  the  winds.  Another,  for  example,  was  the  typhoon  condition 
declarations,  like  Japan  is  in  four  and  Okinawa  is  in  two  and  so  forth;  we  have 
to  keep  track  of  all  that.  Another,  say,  was  of  the  airlift:  how  many  flights 
are  coming  from  where  and  have  they  arrived  yet,  that  sort  of  thing.  So,  as 
an  example,  that  is  just  the  sort  of  thing  we  need  this  kind  of  file  system  for. 

Interviewer:  How  are  the  messages  organized  within  one  of  these  files? 

Respondent:  Normally,  by  date-time  group.  Subject  files  and  within  subject 
by  date-time  group.  But  I  suppose  that  comes  about  by  the  way  messages 
are  manually  filed.  If  you  are  filing  and  retrieving  manually,  then  you  want 
the  most  recent  on  top.  In  a  computer,  I  don’t  know  if  you  want  to  stick  to 
that  or  not. 

Interviewer:  When  you  ask  for  summary  information,  the  excerpts,  perhaps 
you  could  get  them  chronologically.  But  there  are  other  ways  you  can  call 
for  the  information  if  you  want  just  parts  of  it.  We’ll  get  into  that  in  a  few 
minutes. 


Respondent  7 

This  individual  was  primarily  concerned  with  readboards  which  are  files  made  up 
each  day. 

Respondent  8 

Files  are  by  subject  matter  within  a  broad  area  of  interest.  There  are  about  15 
subjects,  and  no  organization  within  a  file.  Messages  per  file  range  from  about  15  to  150. 
Retrieval  is  by  subject,  sometimes  with  the  approximate  DTG. 


Respondent  9 

Longevity  of  files  is  about  three  weeks. 

Respondent  10 

Messages  are  now  retrieved  by  DTG,  subject,  and  originator. 


Respondent  11 


Respondent:  If  I  were  going  to  use  this  system,  I  would  have  to  be  sure  that  I 
knew  what  files  I  had,  from  a  title  standpoint.  It  would  be  difficult  to 
remember  20  or  25  different  files. 

Interviewer:  How  do  you  do  it  now? 

Respondent:  I'd  have  to  have  the  title  in  order  to  be  able  to  file  a  message. 

Interviewer:  One  thing  you  might  do  is  display  the  names  of  all  your  files.  A 
file  name  might,  for  practical  purposes,  be  as  long  as  you  want.  In  the  file 
system  we  use,  I  have  hundreds  of  files  so  my  secretary  gives  them  long 
descriptive  names  to  easily  identify  them.  But  you  aren’t  required  to  type 
the  entire  name. 


Respondent  12 

Messages  are  filed  two  ways:  all  outgoing  in  originator  files,  and  both  incoming  and 
outgoing  in  subject  files.  There  are  about  50  subject  files  run  by  calendar  year.  Some 
would  contain  1000  messages  and  others  as  few  as  100. 


Respondent  13 

There  are  approximately  100  Navy  files  with  5-200  messages  per  file,  and  five  or 
six  subject  files  with  100  messages  each.  Again,  we  quote. 


Respondent:  The  Navy  uses  Standard  Subject  Index  Classification  (SSIC). 
Actually,  I’ve  got  three  different  sets  of  files  because  I’ve  got  three  different 
shops  back  there  that  I  take  care  of.  I  take  care  of  Air,  Ground,  and  Surface. 
The  Navy  has  theirs  by  SSIC,  the  Air  shop  files  by  subject  and  date-time 
group. 


Respondent  14 

Forty  or  fifty  subject  files  are  maintained  in  this  office.  Messages  range  from  6  to 
several  hundred  per  file. 

Respondent:  By  subject  title  within  year.  We  have  several  years  of  files. 
Current  files  are  maintained  for  about  a  year.  We  maintain,  but  seldom  use, 
history  files. 


Respondent  15 


Messages  are  filed  under  title.  The  number  of  active  files  range  from  6  to  70,  and 
30-minute  access  time  is  needed. 


Respondent  16 

Approximately  6  subject  files  of  continuing  interest  are  maintained.  Within  subject, 
messages  are  filed  by  DTG.  We  quote. 

Respondent:  It  depends.  But  I  would  say,  of  continuing  interest,  we  may  have 
half  a  dozen  or  so.  However,  there  are  some  areas  that  we  have  worked  in, 
where,  when  we  see  the  message,  we’ll  go  ahead  and  file  it.  By  the  half 
dozen  or  so,  I’m  saying  these  are  things  we  are  watching  on  a  day-to-day 
basis.  And  those  half  dozen  are  changing.  We  may  dump  them  all  at  the  end 
of  the  month,  and  start  another  one  in  another  category.  But  work  that 
we’ve  done  two  years  ago  —  we  may  still  be  collecting  traffic  on  that.  So 
the  number  of  files  can  run  into  hundreds. 


Respondent  17 

This  subject  presently  has  358  files,  strictly  by  subject,  and  within  by  action  and 
miscellaneous.  Messages  per  file  range  from  20  to  300. 


Respondent  18 

Messages  are  filed  by  subject,  and  by  DTG  within.  Thirty  to  forty  files  are 
maintained  with  1-300  messages  per  file. 


Respondent  19 

Respondent:  In  our  office  we  deal  with  day-to-day  requirements  as  well  as 
historical  requirements  files.  We’re  typically  responsive  to  the  J3  day-to-day 
action  board  in  that  we’re  working  current  operations  problems  as  well  as 
current  operations  problems  that  impact  on  source  documents  that  may  be 
five  years  old,  or  six  years  old  —  JCS  SM’s  or  something  of  that  nature.  So 
if  we’re  talking  of  our  filing  system,  not  only  messages  but  periodicals  and 
SM’s  and  that  sort  of  thing,  we  have  what  we  consider  current  files,  that  go 
back  7  or  8  years.  It  may  seem  a  little  bit  unreal  but  a  lot  of  things  we 
operate  on  are  printed  one  time  and  maintained  as  a  current  item.  In  fact,  I 
was  reviewing  one  this  morning  that  was  dated  1969,  an  SM.  A  lot  of  our 
day-to-day  current  activity  is  based  on  files  that  are  6  or  7  years  old  in  the 
document  area.  Now,  with  regard  to  messages,  in  some  cases  we  keep  files 
of  messages  that  are  2  or  3  years  old.  We  have  been  known  to  have  a  3  or 
4  year  old  message  that,  in  fact,  was  the  only  guidance  we  ever  got  on  that 
particular  subject.  Sometimes  the  information  is  picked  up  in  new  SMs  as 
they  are  published.  We  deal  in  nuclear  safety.  Guidance  comes  out  in 
messages  that  references  a  particular  SM  and  says,  "This  is  an  elaboration  on 
a  particular  point  that  was  discussed  in  the  SM,"  for  instance.  We  would 
maintain  that  file  for  2  or  3  or  4  years. 


Interviewer:  How  many  active  files  do  you  have  at  any  one  time? 

Respondent:  If  we’re  talking  about  specific  subjects  ... 

Interviewer:  Is  that  the  way  they  are  organized? 

Respondent:  Yes.  Subject  files.  For  example,  the - bomb.  If  we  break 

that  down  to  the - bomb,  of  which  there  are  innumerable  kinds  of  bombs, 

we  probably  have  in  the  neighborhood  of  2  to  4  hundred  files. 

Interviewer:  Each  one  would  contain  approximately  how  many  messages? 

Respondent:  Somewhere  between  4  and  12. 

Respondent  20 

Files  are  by  subject  and  within  by  DTG.  Presently  there  are  approximately  15 
current  files  plus  historic  files. 

Respondent  21 

Six  to  10  files  are  maintained,  with  about  5  to  10  messages  per  file.  They  are 
subject  files,  sorted  within  by  DTG.  Large  files  are  organized  within  by  originating 
organization.  We  quote  the  subject. 

Respondent:  They  are  strictly  manual.  Messages  and  pertinent  references 
are  put  into  a  manila  folder.  In  most  cases  there  is  some  classification  that 
requires  you  keep  it  in  a  safe  drawer  that  you  might  have  all  to  your  own  use 
or  you  might  share  with  another  action  officer.  You  keep  correspondence 
that  pertains  to  that  subject  with  that  folder  until  the  action  is  completed,  at 
which  time  you  destroy  the  file.  And  if  you  ever  need  it  in  the  future,  you 
have  to  go  to  the  LDMX  master  archive. 

Respondent  22 

Four  files  are  maintained  by  SPECAT,  Outgoing,  Incoming  and  Eyes  Only.  In  addition 
there  are  general  correspondence  files  (about  10-15)  by  subject,  which  contain  2-150 
messages  per  file. 

4.2  AUTHORS’  COMMENT 

Other  materials  are  integral  to  the  message  handling  processes.  This  very 
important  fact  begins  to  emerge  with  the  subjects’  remarks  in  this  chapter.  We  will  revisit 
this  notion  many  times  throughout  the  report.  Another  noteworthy  observation  is  that 
active  file  storage  requirements  do  not  appear  to  be  excessive,  for  J3,  in  terms  of  modern 
secondary  storage  mediums.  Many  users  are  referring  to  the  same  messages;  some  of  the 
respondents  are  describing  the  same  file.  For  example,  three  respondents  represented  J3 
administration,  and  their  descriptions  referred  to  a  common  file  system. 
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5.  A  GENERAL  AUTOMATED  FILING  SYSTEM 


Our  earlier  study  in  Washington  gave  rise  to  a  general  organization  for  filing  and 
retrieval.  This  file  organization,  based  upon  the  opinions  of  the  Washington  Navy 
personnel  involved  in  the  earlier  study,  was  presented  to  the  subjects.  Our  objective  was 
to  determine  if  it  had  wide  enough  application  to  cover  the  needs  of  the  Oahu  personnel 
who  will  be  using  the  test  service  next  year. 


5.1  A  PROPOSED  FILING  SYSTEM 

5.1.1  Overview  Presented  to  the  Subjects 

We  envision  an  electronic  filing  system  that  is  conceptually  similar  to  a  filing 
cabinet  in  that  you  can  have  any  number  of  files ,  and  any  of  them  can  contain  an 
arbitrary  number  of  messages.  Earlier,  we  mentioned  the  PENDING  file,  which 
automatically  traps  all  your  incoming  traffic.  Now  in  addition,  you  can  have  any  number 
of  personal  files  that  you  want  to  define,  and  we've  given  some  examples  here  (Pig.  5-1) 
with  subject  names.  You  may  organize  according  to  subject,  or  organize  according  to 
action,  cog.,  info.,  or  whatever  you  desire  —  any  arrangement  you  like.  Additionally,  there 
are  a  number  of  files  that  may  be  accessed  by  more  than  one  person:  as  examples,  the 
daily  digest  and  readboards.  In  addition  to  the  types  of  files  seen  here,  there  is  a  master 
archive  that  will  contain  a  copy  of  all  of  the  released  messages,  not  Just  J3’s ,  but  all  of 
them.  It  would  be  accessed  on  the  originator  and  date-time  group.  Now,  in  addition, 
associated  with  each  one  of  your  personal  files  and  group  files,  there  is  a  special  separate 
archive  file,  so  that  you  can  clean  up  your  active  files  and  put  messages  in  an  archive. 
You  still  retrieve  messages  on  the  same  basis  that  you  would  retrieve  from  an  on-line  file. 
What  you  have  now,  in  fact,  is  a  master  archive.  You  go  back  through  LDMX  to  retrieve  an 
old  message  if  you  don't  have  a  hardcopy  of  it.  And  you  either  give  them  the  control 
number  or  the  originator  and  date-time  group.  Something  on  that  order?  We  have  some 
easier  ways,  and  we  hope  you  can  do  it  yourself,  directly.  We'll  get  into  some  of  those  in  a 
few  minutes. 

The  kinds  of  things  that  you  can  do  with  these  files  is,  of  course,  to  put  messages 
into  them,  and  take  messages  out  for  display  or  for  making  printed  copies,  for  opening  up 
other  offices,  archiving  and  unarchiving,  and  so  forth.  The  master  archive  will  be  updated 
automatically:  every  incoming  message  will  be  copied  into  the  master  archive.  You  can 
have  the  service  automatically  clean  up  your  personal  files  for  you,  based  on  certain 
criteria,  or  you  can  do  it  explicitly  yourself.  And  in  a  few  minutes  I'll  describe  some 
features  and  let  you  decide  which  way  you'd  prefer  to  do  that. 

With  these  files,  you  can  extract  only  a  part  or  a  subset  of  the  file  that’s  of  interest 
to  you.  For  example,  let’s  say  that  you  have  a  personal  file  labeled  SPECAT  containing 
your  SPECAT  messages,  and  you  only  want  to  look  at  those  that  were  originated  by  PACAF. 
You  could  extract  only  those  headers,  or  the  messages  themselves,  of  interest  to  you, 
instead  of  looking  at  the  entire  file.  We  have  some  ways  of  doing  this,  to  hopefully  specify 
a  particular  message  in  a  file  of  maybe  several  hundred.  We’U  talk  about  that  in  a  few 
minutes. 


5.1.2  A  Question  on  the  General  File  Organization 

The  first  thing  Pd  like  you  to  do,  though,  is  to  rate  numerically  this  general  file 
organization  as  to  its  adequacy  for  your  needs. 


5.1.3  Analysis  of  Responses  to  the  General  File  Organization  and  Operation 

Responses  to  the  general  description  of  an  automated  filing  system  are  shown  in  Fig. 
5-2.  Approximately  half  of  the  subjects  felt  that  this  capability  teas  highly  desirable, 
and  approximately  half  stated  that  it  teas  essential.  Note  the  most  common  reply  (mode  - 
3)  was  "necessary."  Note  also  the  low  variation  in  responses  (std.  dev.  -  0.8). 

I 

5.2  READBOARDS  AND  OTHER  GROUP  FILES 

There  was  no  numerically  rated  question  for  readboard  organization.  To  those  who 
use  them,  they  are  essential!  to  those  who  do  not,  they  are  not  needed.  Our  objective 
was  to  ascertain  the  composition  and  use  of  readboards. 


5.2.1  A  Question  on  Files  Requiring  Special  Handling 

What  are  the  kinds  of  files  you  deal  with  that  require  special  handling?  And  what 
are  the  special  features  of  each ?  For  example,  if  the  action  tog  were  a  file,  it  would  have 
specially  formatted  entries,  different  from  messages,  and  part  of  each  entry  could  be  filled 
in  automatically  by  the  service. 


5.2.2  Remarks  on  Special  Files 


Respondent:  The  daily  digest  contains  incoming  documents  and  efficiency 
reports.  Anything  with  a  suspense  date  they  pick  up  for  the  digest.  As  far 
as  messages  go,  it  could  be  a  file. 


Respondent:  I’m  thinking  of  the  watch  team  requirements  versus  the  staff 
agency  requirements.  I  build  three  readboards  myself. 

Interviewer:  When  you  are  building  them,  do  you  look  at  a  message  and  then 
decide  to  put  it  on  one  board  or  another? 

Respondent:  Right.  I  have  General - ’s  and  Colonel - ’s  and  Colonel 

- ’s.  Every  message  that  comes  in  goes  across  my  desk.  I  make  a 

determination  if  that  message  should  go  in  any  or  all  of  those  readboards. 

Interviewer:  So,  it  might  go  on  more  than  one? 


Respondent:  Yes. 
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Interviewer:  Is  that  based  on  the  subject  line  of  the  message? 

Respondent:  Normally,  the  readboard  is  divided  into  sections.  Certain  things 
will  go  in  without  my  determination.  They  automatically  go  in  or  they  do  not. 
For  example,  OPREP-3  is  a  message  of  command  interest  that  comes  up  from 
subordinate  units:  every  one  of  those  will  go  in. 

Interviewer:  Is  OPREP-3  a  message  type? 

Respondent:  Yes. 

Interviewer:  Is  it  on  a  different  form? 

Respondent:  No.  It’s  on  the  same  form,  it  is  just  a  flagword. 

Interviewer:  So,  you  pick  that  up  from  the  first  part  of  the  text? 

Respondent:  It's  in  the  subject.  There  might  be  additional  flagwords,  like 
"pinnacle",  which  means  it  goes  all  the  way  to  the  top. 

Interviewer:  Is  there  any  information,  other  than  the  subject  line,  that  you  use 
in  determining  on  which  readboards  it  should  go? 

Respondent:  That’s  interesting.  Oealing  with  this  volume  of  messages,  I 
suppose  everyone  develops  their  own  technique.  I  try  to  look  at  the  subject 
line  and  down  at  the  bottom  where  the  computer  has  flagged  it  for  J3  action 
or  cog. 

Interviewer:  So  you  look  at  action  assignment  as  well. 

Respondent:  Yes.  The  reason  I  look  at  the  subject  is  because  the  readboards 
are  sectioned.  Section  one  is  OPREP-3  and  locator  bulletins,  section  two  is 
SPECAT  messages,  section  three  is  J3  action/cog,  section  four  is  then 
messages  other  than  J3  action/cog  that  would  be  of  interest  to  J3. 

Interviewer:  You  mentioned  SPECAT.  So  you  are  also  looking  at  special 
handling  codes.  That  is  also  a  part  of  the  first  line. 

Respondent:  Yes.  But  those  presently  come  on  pink  paper  rather  than  white, 
so  I  know  immediately.  Other  than  the  J3  action/cog,  I  look  at  the  subject 
and  if  it  is  something  that  is  current  or  hot,  although  the  message  is  not 
flagged  for  J3,  I  know.  Or  the  DDO  knows,  because  he  goes  to  all  the  daily 
briefings.  He  chooses  more  of  those  because  he  is  in  the  mainstream  and 
knows  what’s  of  current  interest  to  the  J3  staff.  For  example,  there  might  be 
something  put  in  there  today  that  you  wouldn’t  have  put  in  yesterday, 
whereas  tomorrow  they  may  not  want  to  read  about  it. 

On  my  team,  the  DDO  also  gets  a  copy  of  all  messages.  He  also 
determines  messages  that  are  not  J3  action  or  cog,  but  that  would  be  of 
interest  to  the  J3  staff.  So  he  gives  me  a  copy  and  I  put  it  in  the  reading 

board.  Sometimes,  he’ll  put  one  in  just  for  General - or  Colonel - . 

So,  we’re  both  reading  the  subject. 


34 


Interviewer:  How  big  are  these  three  readboards? 

Respondent:  It  varies  with  the  volume  of  traffic.  Normally,  I’d  say  around  50 
messages.  We’re  doing  this  after  duty  hours.  From  three  in  the  afternoon 
until  six  in  the  morning,  we  build  readboards.  Through  the  day,  the 
distribution  is  made  through  the  agency  itself. 

Interviewer:  How  long  does  a  message  stay  there? 

Respondent:  Just  until  they  read  it.  For  example,  Colonel - comes  in  at 

4:30  or  5:00  in  the  morning.  He  goes  through  them  and  highlights  things  that 
he  thinks  would  be  of  general  interest. 

Interviewer:  Who  takes  the  messages  off  the  readboards? 

Respondent:  After  they  have  finished  with  it,  their  clerk  will  bring  it  back  to 
me. 

Interviewer:  They’ve  indicated  on  there  what  should  be  deleted? 

Respondent:  No.  I  just  throw  them  all  away.  The  only  value  of  those 
messages  was  for  them  to  read.  There  are  other  copies  for  them  to  file. 

Interviewer:  It  is  just  a  one-day  activity? 

Respondent:  Yes.  Now  sometimes  the  General  or  the  two  Colonels  might  see 
a  message  they  want  to  flag  back  to  the  DDO.  For  example,  the  earthquake 
message  was  pulled  out  and  commented:  "Watch  this  over  the  weekend”  and  it 
went  back  to  the  DDO.  So  sometimes  the  messages  are  pulled  out  of  the 
readboards  for  actions. 


Respondent:  I  make  up  General  - ’s  readboard.  From  1500  in  the 

afternoon  until  6:00  in  the  morning.  For  the  message  traffic  that  comes  to 
CINCPAC  between  those  hours,  it  is  the  guy  on  my  desk  who  decides  what  the 
General  is  going  to  see  (when  he  comes  in  at  6:30  in  the  morning)  from  the 
afternoon  and  evening  before. 

Interviewer:  Is  this  a  single  readboard? 

Respondent:  Yes,  it  is. 

Interviewer:  Do  you  make  up  copies  for  others  as  well? 

Respondent:  I  make  up  three  of  them  simultaneously. 

Interviewer:  Do  you  put  the  same  things  into  each  of  them? 

Respondent:  Yes,  with  some  very  minor  exceptions. 


Interviewer:  With  an  electronic  readboard,  would  it  be  acceptable  to  make  up 
just  one  and  mark  some  items  not  of  interest  to  certain  individuals?  Or  would 
you  s^  ;se  three? 

Respondent:  As  far  as  messages  go,  they  all  get  the  same  messages.  It's 
soma  of  the  other  stuff. 

Interviewer:  What  other  stuff? 

Respondent:  We  have  personnel  locators,  not  in  message  form,  that  the  EAs 
(Emergency  Action  Team)  make  up. 

Interviewer:  What  is  a  personnel  locator? 

Respondent:  It  tells  where  all  the  major  people  are.  Each  night  the  EAs  work 
that  up  for  the  next  day.  If  someone  doesn’t  happen  to  be  in  the 
Headquarters,  if  they  are  on  leave  or  something,  it  is  indicated  here,  along 
with  when  they’ll  return. 

Interviewer:  This  goes  on  a  form? 

Respondent:  Yes. 

Interviewer:  And  there  is  just  one  copy  of  it  that  goes  on  each  of  the 
readboards?  Would  it  be  possible  for  us  to  get  a  copy  of  the  form? 

Respondent:  Sure.  We  also  have  a  feu  others  that  ue  make  up  —  status  of 
our  airborne  command  post  airplanes,  status  of  our  T  AC  A  MO  airplanes. 

Interviewer:  Again,  these  are  standard  forms  that  you  complete  each  day? 

Respondent:  Yes. 

Interviewer:  I  would  imagine  that  with  some  of  these  forms,  such  as  the 
personnel  locator  form,  it  is  already  filled  out  with  the  names  or  codes  and 
you  just  do  minor  editing  on  it  each  day. 

Respondent:  Right. 

Interviewer:  It  is  certainly  possible  to  have  that  kind  of  form  in  the  computer 
and  you  could  edit  it  each  day  and  put  it  in  the  readboards. 

5.3  INTERPRETATIONS  AND  RECOMMENDATIONS 

Twenty-two  of  24  subjects  were  generally  quite  pleased  with  the  basic  architecture 
of  the  file  system  described.  Our  understanding,  at  this  level,  of  their  needs  is  precise 
enough.  However,  it  is  the  details  that  will  ultimately  render  the  service  useful  or  not. 
We  are  about  to  embark  upon  those  details  in  the  next  few  chapters.  But  let  us  not 
overlook  the  few  important  details  uncovered  in  discussing  the  general  organization.  The 
first,  italicized  earlier,  is  that  SPECATs  are  differentiated  by  color  coding.  Bordering  or 


some  other  form  of  electronic  emphasizing  is  recommended  for  SPECATs,  either  ,ill  of  them 
or  at  least  those  routed  to  the  command  center. 

The  next  detail  is  very,  very  important.  Readboards  contain  nonmessage  forms, 
edited  daily.  Incorporating  these  forms  should  not  be  difficult  nor  time-consuming.  The 
authors  have  earlier  mailed  copies  of  them  to  BBN,  MIT,  and  USC/ISI.  We  recommend  their 
inclusion.  Quite  a  few  subjects  raised  and  reraised  the  issue  —  the  problem  —  of 
preforming  their  daily  functions  using  electronic  message  handling  while  at  the  same  time 
using  present  manual  procedures  for  nonmessage  materials.  We  mentioned  this  in  an 
earlier  chapter;  you  will  see  it  again.  We  highly  recommend  automating  as  many  as 
possible  of  these  nonmessage  materials.  Many  should  be  straightforward,  others 
completely  impractical  for  the  1977  test.  We  consider  the  readboard  nonmessage  items  to 
belong  to  the  former  category. 


6.  PROGRAMMABLE  FILE  FEATURES 


This  chapter  covers  an  assortment  of  file  features  planned  to  provide  the  flexibility 
necessary  to  satisfy  the  divergent  filing  needs  of  various  military  agencies. 


6.1  OVERVIEW  OF  FILE  FEATURES  PRESENTED  TO  THE  SUBJECTS 


We’d  like  to  talk  about  the  u/ays  you  can  organize  and  control  files.  And  then  u/e’U 
talk  about  the  explicit  operations  using  the  keyboard  to  get  information  in  and  out.  Let’s 
talk  about  the  organization  of  a  file  first. 

This  (Fig.  6-1)  is  a  file  header  that  you  could  specify  differently  for  each  one  of 
your  files.  It  tells  how  the  file  is  going  to  work.  Here,  we’ve  given  an  example  of  a  file 
called  VISITORS.  Now,  this  isn’t  necessarily  something  you  would  deal  with,  but  it  will 
give  you  an  idea  of  how  the  filing  system  works.  T he  first  item  is  the  name  of  the  file.  It 
is  the  VISITORS  file. 

The  next  area  is  for  notes;  you  can  type  anything  in  here  that  you  want  about  the 
file.  This  is  equivalent  to  just  writing  something  on  the  outside  of  your  present  manila 
file  folder. 

The  next  thing  is  the  access  privileges  which  indicate  who  has  access  to  that  file, 
other  than  you  as  the  owner  of  the  file,  and  any  other  privileges  they  may  have.  Now,  the 
way  this  would  work  is  that  you  would  type  in  here  a  list  of  names  or  office  codes,  and  for 
each  office  code  in  the  list  you  could  type  a  check  mark  in  any  of  these  columns  indicating 
the  privileges  that  they  have  with  respect  to  this  file.  Hardcopy:  to  print  out  hardcopies  of 
messages  in  the  file.  Annotate  allows  them  to  add  notes  or  comments  to  individual  entries. 
Append  gives  them  the  capability  to  add  messages  to  a  file.  Delete  allows  them  to  delete 
messages  from  a  file,  and  own  is  the  individual  who  owns  the  file. 

An  important  concept  of  this  filing  system  is  this  input  filter,  and  the  way  this 
would  work  is  that  every  incoming  message  would  automatically  be  checked  against  every 
one  of  your  files.  If  the  conditions  of  the  input  filter  are  matched  in  the  message,  the 
message  will  be  copied  to  the  file.  Now,  as  an  example,  in  this  VISITORS  file,  any 
message  that  has  in  the  subject  field  the  word  "visitors"  or  in  the  subject  field  the  word 
" arrangements “  would  be  copied  into  this  file.  This  can  work  on  any  fields  of  the  message. 
You  might  be  interested  in  originator,  flagwords,  or  subject.  It  can  be  specified  differently 
for  different  files. 

The  fields  for  retrieval  allows  you  to  specify  the  fields  in  the  message  that  you  will 
later  use  to  select  messages  from  this  file.  And,  as  an  example,  we  say  that  any  message 
in  this  file  can  be  retrieved  by  precedence  field  or  originator  field  or  the  subject  field. 
Again,  you  can  select  any  of  the  fields  of  the  message  you  want  for  this  and  it  can  be 
different  for  different  files.  It’s  up  to  you. 

The  display  format  allows  you  to  specify  how  the  excerpts  or  header  information  will 
look  when  you  ask  to  display  excerpts  of  the  messages  that  are  m  a  file.  F or  this  file,  as 
an  example,  we  have  arranged  it  in  terms  of  security  classification,  precedence,  action. 


date-time  group,  originator,  and  part  of  the  subject  string.  Now  the  display  format  in  the 
file  header  will  allow  you  to  specify,  if  you  want  to,  different  display  formats  for  different 
files,  and  also  you  may  specify  them  differently  based  on  the  sources  of  messages.  Again, 
this  is  up  to  you  and  you  could  select  some  standard  format  if  you  want  to. 

We  allow  you  to  specify  file  storage  time  which  indicates  how  long  unreferenced 
messages  will  stay  in  this  file  before  they  are  automatically  backed  up  on  magnetic  tape. 
Again,  this  something  that  you  could  specify  differently  for  each  one  of  your  files,  if  you 
wanted  to. 

The  instructions  allow  you  to  specify  some  additional  things  that  you  want  done  to 
every  message  coming  into  a  file.  As  an  example,  we've  indicated  that  every  message 
coming  in  would  be  hardcopied.  In  fact,  you  could  have  a  list  of  instructions,  for  example, 
to  forward  messages  to  other  individuals,  or  you  could  have  nothing.  It’s  up  to  you  and  it 
could  be  different  for  different  files. 

6.2  ACCESS  PRIVILEGES 


6.2.1  A  Question  on  File  Access  Privileges 

Now,  we’d  like  for  you  to  numerically  rate  these  various  features  beginning  with  the 
access  privileges. 

6.2.2  Analysis  of  Responses  to  Access  Privileges 

Figure  6-2  shows  their  responses.  Twelve  of  21  respondents  who  answered  the 
question  considered  this  feature  essential.  There  was  no  significant  variation  among 
subgroups. 

6.2.3  Remarks  on  File  Access  Privileges 

Respondent:  We  just  want  to  make  sure  that  people  can  get  to  our  messages 
but  not  delete  them. 


Respondent:  In  a  system  like  this,  you  have  to  have  something  to  preclude 
everyone  from  getting  access  to  things  they  have  no  need  for. 


Respondent:  /  see  that  as  having  to  he  in  some  sort  of  tree  structure  because, 
for  instance,  J31  should  be  able  to  get  into  the  files  of  any  branch  in  31;  311, 
312,  313.  And  I  should  think  that  would  be  implicit  in  the  system.  You 
absolutely  have  to. 
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HARDCOPY 

Fig.  6-1  Example  File  Header 
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Fig.  6-2  Ratings  for  File  Access  Priviliges 


Interviewer:  If  it  is  as  simple  as  that,  then  we  certainly  don’t  need  this 
mechanism  --  if  it  really,  in  fact,  is  a  tree  structure. 

Respondent:  Well,  there  might  be  other  people  besides  that.  For  example,  I 
might  want  to  have  J6  access  my  file  on  communications. 

Interviewer:  There  is  no  problem  in  the  tree  structure  case  of  subordinate 
compromise,  where  you  really  don’t  want  your  boss  to  know  what  you  are 
fiddling  around  with  in  your  file  right  now? 

Respondent:  I  don’t  think  there  should  be.  He  is  the  boss,  after  all.  He 
should  be  able  to  see  what  is  going  on.  That’s  the  way  it  is  right  now.  He 
gets  everything  that  comes  to  J— .  That’s  as  it  should  be. 

Interviewer:  Okay,  so  we  should  have  the  implicit  tree  structure  or  org  chart, 
and  in  addition  allow  you  to  designate  others  who  could  access  a  file. 


Respondent:  You  don’t  need  names  because  people  leave.  Codes  are  fine. 
The  DDO  is  like  a  code,  it  is  necessary. 


Respondent:  Let  me  ask  a  question.  This  system  is  on  GENSER  traffic  right 
now? 

Interviewer:  Yes.  GENSER  traffic  to  top  secret. 

Respondent:  Is  it  ever  going  into  SI? 

Interviewer:  This  test  system  is  not,  to  my  knowledge.  But  an  operational 
system  that  might  he  huilt  from  the  lest  would  probably  handle  multilevel 
security  in  GENSER  and  SI. 

Respondent:  Okay.  On  that  basis,  /  say  yes.  You  need  it  because  there  are 
people  who  would  not  have  the  clearances  to  take  a  look  at  messages,  and  we 
would  have  to  be  the  arbitrators  of  that.  So  I  agree  with  all  of  this. 


Respondent:  I  suppose  what  it  does  is  protect  and  give  you  some  privacy  over 
what  you  are  building  in  your  file.  It  depends  on  the  range  of  users  who 
might  be  able  to  access  your  file.  If  you  assume  a  fairly  small  group  of 
people  who  might  be  able  to  access  your  file,  let’s  say  any  action  officer 
within  CINCPAC  Headquarters,  then  I  wouldn’t  worry  that  much  about  it. 

Interviewer:  Is  that  the  range  of  people  who  have  access  to  your  files? 

Respondent:  Surely.  If  anyone  comes  in  and  asks  me  to  see  a  message,  I 
don’t  say  "I  can’t  show  it  to  you,  it  is  private."  I  consider  anything  I  do 
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officially  as  open  to  anybody  with  official  status.  But  if  you're  considering 
the  possibility  of  access  from  outside  the  Headquarters,  beyond  the  component 
level  ... 

Interviewer:  Not  in  the  1977  test,  but  certainly  in  an  operational  system, 
there  would  be  a  saturation  of  terminals  here  on  the  Island  and  also  at  other 
locations. 

Respondent:  In  that  case  I  think  that  would  be  a  plus  three. 


6.2.4  A  Question  on  Changes  to  the  Proposed  Schema 


What  about  these  particular  privileges  u/e've  indicated  (Fi(».  6-1)7  We  listed  all  we 
could  think  of,  but,  for  example,  if  everyone  who  can  read  a  file  (that  is,  everyone  whose 
name  or  code  you  put  there)  can  also  make  printed  copies,  then  there  wouldn't  be  any 
point  in  our  having  that  column  and  forcing  you  to  make  check  marks  there.  We’d  just 
leave  it  off.  Likewise,  for  example,  if  no  one  except  the  owner  could  delete  entries,  then 
there  wouldn't  be  any  point  in  having  it  there  because  you’d  never  put  a  check  mark  there. 
So,  if  there  are  any  columns  where  you  would  never  put  a  check  mark  or  you  always 
would,  then  tell  me  and  we  can  just  omit  those  columns. 


6.2.5  Analysis  of  Responses  to  Changing  Privileges 

As  long  as  the  test  service  is  confined  to  GENSER  traffic  within  the  Headquarters,  no 
one  cared  to  restrict  hardcopy  separately  from  the  read  privilege.  About  half  the 
subjects  felt  the  same  about  annotation.  All  felt  that  delete  should  be  closed  to  the 
ownership.  Most  felt  that  append  should  remain  distinct  as  an  optional  privilege. 


6.2.6  Remarks  on  Changes  to  the  Proposed  Schema 


Respondent:  You  don’t  need  hardcopy  and  annotate. 


Respondent:  If  you  are  looking  at  just  CENSER  traffic  in  this  building,  then 
I  would  say  you  could  delete  hardcopy  because  anyone  who  we  would  open 
up  on  it,  we  would  have  no  objections  to  them  making  a  hardcopy. 

Interviewer:  With  the  GENSER  traffic,  would  it  also  be  okay  for  them  to  make 
remarks  in  the  file,  the  annotation? 


Respondent:  It  doesn’t  matter. 


6.3  INPUT  FILTER  FOR  FILING  MESSAGES  AUTOMATICALLY 


6.3.1  The  Question  of  Automatic  Filing 

What  awui  the  input  filter  —  the  capability  of  being  able  to  automatically  trap 
copies  of  incoming  messages  and  file  them  according  to  subject,  SSIC  code,  or  u/hatet/er 
you  want?  How  would  you  rate  that  capability? 


6.3.2  Analysis  of  Responses  to  Automatic  Filing 

Figure  6-3  (p.  47)  illustrates  the  responses.  The  subjects  were  fairly  evenly 
divided  between  highly  desirable  and  necessary. 


6.3.3  Remarks  on  Automatic  Filing 


Respondent:  As  long  as  it  also  goes  into  your  PENDING  file,  this  is  excellent. 


Respondent:  That’s  a  necessary  requirement. 


Respondent:  Conceptually,  it  is  a  nice  idea.  Hut  I  can’t  visualize  defining 
constraints  specifically  enough  to  make  it  of  any  use.  For  example,  you  list 
"visitors"  here,  and  visitors  is  one  of  the  things  we  try  to  keep  track  of.  But 
visitors  fall  within  so  many  categories  with  so  many  special  exceptions,  that  I 
just  can’t  see  putting  together  a  subject  definition  that  would  include  all  of 
the  visitors  we  are  interested  in.  I  don’t  know  how  you  could  define  it  to  suit 
our  needs. 

Interviewer:  Within  your  15  subject  files,  how  do  you  classify  a  message  now? 
What  determines  which  file  it  goes  in? 

Respondent:  The  content  of  the  message.  The  text. 


Respondent:  The  right  keywords  will  trap  most  of  them. 


Respondent:  How  do  you  know  you  aren’t  missing  something? 

Interviewer:  A  copy  will  always,  automatically  go  in  your  PENDING  file.  You 
can  display  the  excerpts  of  a  subject  file  to  see  what’s  there. 


Respondent:  Okay. 


Respondent:  Based  upon  my  experience  to  date,  I  am  "anti”.  I  know  the 
system  can  be  cleaned  up.  I  would  rate  that  a  plus  two. 

Interviewer:  The  way  LDMX  works  right  now  in  looking  at  the  message  is  very 
fixed  for  everyone.  Here,  we’re  trying  to  give  the  ability  to  specify  the  way 
it  should  look  for  you  and  what  it  should  look  for. 


6.4  PRESPECIFICATION  OF  FIELDS  FOR  MESSAGE  RETRIEVAL 

6.4.1  A  Retrieval  Question 

What  about  the  specification  of  retrieval  conditions?  What  rating  would  you  give 

that? 


6.4.2  Analysis  of  Responses  to  Prespecification  of  Retrieval  Conditions 

Overall,  subjects  rated  this  highly  desirable,  with  a  mean  -  2.2,  std.  dev.  »  0.9, 
and  mode  -  2.  There  was  a  significant  difference  between  the  responses  of  the  enlisted 
personnel  in  administration  and  each  other  subgroup.  The  administration  personnel 
considered  the  retrieval  filter  essential;  see  Fig.  6-4.  Figure  6-5  shows  the  responses  of 
all  subjects  except  administration  personnel.  Considered  independently,  each  of  these 
other  subgroups  rated  this  feature  highly  desirable. 


6.4.3  Remarks  on  Prespecification  of  Retrieval  Conditions 


Respondent:  Plus  three.  That  is  half  of  our  work,  retrieving  messages. 


Respondent:  I  could  foresee,  especially  during  a  crisis  where  the  traffic  does 
get  very  voluminous,  that  you  would  want  to  screen  messages  so  that  you 
look  only  at  flash  or  immediate. 

Interviewer:  If  you  retrieved  it  by  stating  date-time  group  within  a  period  of  a 
month,  that  should  certainly  cut  down  on  the  number  of  message  headers 
you’d  have  to  scan  to  pick  out  the  one  you  wanted. 

Respondent:  That’s  assuming  that  the  subject  you  see  in  your  mind  is  the 
same  one  that’s  listed  in  the  computer  for  the  message.  I  used  the  example 
of  ammunition  in  Korea  before.  Suppose  I  want  to  go  back  and  find  out  about 
ammunition  storage  in  Korea,  but  the  message  may  be  listed  under  the  topic 
of  "Construction  of  Storage  Sites."  There  might  not  be  compatibility  of 
terminology. 


Interviewer:  Let  me  suggest  something  else  that  might  be  more  useful. 
Instead  of  using  the  subject,  you  could  use  keywords  that  you  generate.  If 
you  are  going  to  remember  a  message  by  ammunition,  then  enter  it  with  that 
as  a  keyword. 

Respondent:  But  the  originator  of  the  message  in  Korea  doesn’t  have  my 
flagword. 

Interviewer:  But  we’re  talking  about  your  personal  filing  system.  You’re  the 
one  recalling  the  message.  Would  you  not  remember  that,  when  filing,  you 
had  made  the  association  between  that  message  and  the  word  ammunition? 

Respondent:  It’s  difficult  to  say.  You  see  a  wide  variety  of  messages  dealing 
with  a  wide  variety  of  subjects. 


Respondent:  You  can  spend  hours  just  looking  for  one  message  now. 


Respondent:  Probably  the  originator,  subject,  and  time  frame.  By  that  I 
mean  we  know  the  message  came  in  in  September  of  1975. 


Respondent:  Note,  that  means  you  can't  make  an  ad  hoc  retrieval.  As  you  are 
going  through  or  working  on  your  files,  you  couldn’t  say  I’d  like  to  get  it  by 

subject  or  I’d  like  to  get  a  message  if  it  has  the  word - in  it,  or  something 

like  that. 

Interviewer:  Let’s  say,  for  example,  that  you  had  given  just  this:  subject, 
originator,  and  precedence.  Now,  date-time  group  range  is  implied  --  you  can 
always  retrieve  on  the  basis  of  that.  Later  you  want  to  retrieve  this  on  the 
basis  of  SSIC  code.  You  wouldn’t  be  allowed  to  do  that.  And  it  may  seem  a 
little  obscure  to  you,  as  to  why  that  is  true,  but  it  has  to  do  with  a  possible 
internal  organization  of  a  file.  This  organization  would  allow  the 
implementers  to  save  space  by  not  maintaining  any  other  attributes  than  the 
ones  you  list  here.  This  retrieval  filter,  of  course,  is  there  to  help  the 
implementers,  not  you.  You  could  omit  the  retrieval  filter  and  retrieve  on  any 
field,  but  that  would  require  more  file  storage  and  thus  more  dollars. 

Respondent:  Do  you  consider  the  body  of  the  message  a  field? 

Interviewer:  It  is  a  field  in  a  sense.  We  don’t  envision  the  capability  of 
searching  for  matches  on  words  or  phrases  throughout  the  text.  But  if  that 
is  important  to  you,  then  say  so  and  give  it  a  rating  and  I’ll  report  that  to 
those  people  who  are  building  the  services.  Would  that  be  of  value  to  you? 

Respondent:  Yes  it  is.  I’d  give  that  a  plus  one.  For  whatever  reasons,  good 
or  bad,  you  might  be  looking  in  a  hurry  to  find  a  message  that  had  a 


particular  word  or  phrase  in  it.  You  know  what  that  was  but  you  couldn’t 
remember  exactly  what  message  it  appeared  in. 

6.5  THE  FORMAT  OF  MESSAGE  EXCERPTS 


6.5.1  A  Question  on  the  Format  of  Message  Excerpts 

What  about  the  display  format  of  these  message  headers  or  excerpts?  Again,  you 
could  have  the  capability  of  specifying  the  format  and  content  of  that  header  information. 
How  would  you  rate  the  ability  to  be  able  to  specify  the  way  in  which  you  want  to  see 
those  headers?  And  would  you  do  it  differently  for  different  files? 

6.5.2  Analysis  of  Responses  to  the  Format  of  Message  Excerpts 

Figure  6-6  gives  the  rather  curious  set  of  responses.  Although  the  most  common 
reply  was  "necessary  requirement,"  (mode  »  3)  the  mean  response  was  useful,  (mean  = 
1.7).  The  standard  deviation  is  rather  high,  although  there  was  no  significant  difference  in 
responses  among  the  subgroups. 

Thirteen  subjects  answered  the  question  of  whether  this  setting  should  be  a  global 
parameter  or  whether  it  should  be  file-specific.  Only  four  of  13  felt  that  they  would 
apply  the  definition  differently  for  different  files,  yet  three  Of  the  four  rated  the  anility  to 
do  so  as  essential. 


6.5.3  Remarks  on  the  Format  of  Message  Excerpts 

Respondent:  Plus  one.  That’s  desirable.  It’s  not  mandatory.  I  could  accept 
whatever  is  set  up.  Zero  for  different  files.  I  would  not  do  it  differently.  I 
want  the  subject  line  first. 


Respondent:  Minus  three.  I  think  it  should  go  originator,  date-time  group, 
action/info.,  and  precedence  at  the  end.  I  think  the  system  should  provide 
one  print  out  for  the  entire  staff.  There  should  not  be  that  flexibility.  It’s  an 
unneeded  expense. 

6.6  INSTRUCTIONS  APPLIED  TO  EACH  FILED  MESSAGE 


6.6.1  A  Question  on  Programmed  Instructions 

Now,  what  about  the  programmed  instructions?  Every  time  a  message  goes  into  a 
file,  either  automatically  or  by  explicit  filing,  you  could  have  some  other  operations 
performed  on  that  message,  such  as  in  this  case  hardcopying,  or  perhaps  opening  another 
office.  How  do  you  rate  this? 


6.6.2  Analysis  of  Responses  to  Programmed  Instructions 


Taken  as  a  whole,  we  have  a  bimodai  distribution  of  replies  with  mean  =  1.7,  std. 
dev.  »  1.1,  and  mode  3  2.  Examined  as  subgroups,  there  are  two  significant  differences. 
Enlisted  men  had  a  mean  =  2.5  and  std.  dev.  =  0.5,  contrasted  with  officers  whose  mean 
=  1.2  and  std.  dev.  =  1.1.  The  essence  of  this  difference  appears  in  a  small  subgroup  of 
these  divisions.  That  is,  as  shown  in  Fig.  6-7  and  Fig.  6-8,  enlisted  personnel  who 
support  action  officers  rated  this  highly  desirable,  with  very  little  intragroup  variation 
(std.  dev.  =  0.5),  while  action  officers  rated  it  useful,  but  with  much  more  variety  of 
opinion  within  the  group  (std.  dev.  =  1.2). 


6.6.3  Remarks  on  Programmed  Instructions 


Respondent:  For  example,  every  SPECAT  is  sent  to  the  front  office.  I  could 
send  it  automatically. 


Respondent:  It  is  highly  desirable.  It  is  useful  to  me  because  a  lot  of  our 
work  is  routine.  I  could  put  in  instructions  to  take  care  of  it. 


Respondent:  I  could  do  that  without  going  to  the  computer.  I  could  do  that 
through  the  comm  center. 

Interviewer:  That’s  true.  And  it  would  take  you  a  lot  longer.  There  is  a  lot 
more  work  involved  in  that. 

Respondent:  I  think  the  hardcopy  is  going  to  be  the  working  document.  I  can’t 
see  people  going  to  the  computer  and  calling  up  messages  and  reading  them, 
and  then  calling  up  another  one.  What  they  are  going  to  do  is  get  hardcopy 
and  carry  it  around,  a  wad  in  their  hand,  and  page  through  it. 

Interviewer:  Perhaps  some  will  and  others  won’t.  If  the  service  provides 
useful  functions,  some  people  may  choose  to  use  them. 


6.7  INTERPRETATIONS  AND  RECOMMENDATIONS 

Regarding  access  privileges,  we  feel  that  the  ability  to  assign  read  access  to  files  is 
needed.  Subjects  were  asked  to  comment  on  the  procedure  for  doing  so,  implied  by  Fig. 
6-1,  that  is,  entering  office  codes  in  tabular  form  and  checking  boxes  for  additional 
privileges.  No  one  objected  to  this  form,  nor  suggested  an  alternative.  We  continue  to 
generally  recommend  this  tabular  form  for  lists  rather  than  using  parameterized 
instructions.  The  office  code  entry  implies  the  read  privilege.  For  GENSER  messages 
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within  CINCPAC,  the  read  privilege  should  imply  the  hardcopy  privilege.  It  is  debatable  as 
to  whether  read  should  imply  annotate.  The  delete  privilege  probably  should  not  appear 
in  the  matrix;  it  might  inadvertently  cause  more  harm  than  good.  In  general  it  is  not 
needed.  For  example,  in  administration,  those  who  would  we  feel  that  delete  share  a 
common  office  code,  and  we  feel  that  delete  should  be  based  on  office  code,  not  personal 
name  or  password.  In  the  command  center,  there  could  arise  a  need  for  those  other  than 
the  owner  of  the  file  to  delete,  for  example,  DDO  and  J--.  For  this  exception,  one  might 
use  an  explicit  instruction  form  to  assign  the  delete  privilege,  rather  than  the  tabular  list. 
Although  no  one  suggested  removing  the  append  privilege  from  the  matrix,  neither  did 
anyone  offer  an  example  of  its  use  in  their  job  function,  with  the  exception  of  readboard 
construction. 

As  pointed  out  by  italics  in  the  dialogue,  one  respondent  identified  the  need  for 
implied  hierarchical  access  based  on  organizational  structure.  Although  the  access 
requirement  may  exist,  it  can  be  easily  assigned  explicitly  through  the  proposed  scheme  of 
typing  in  office  codes.  Therefore,  we  would  class  this  proposed  feature  (that  is,  building 
it  into  the  service)  as  a  nicety  rather  than  a  necessity.  If  the  designers  plan  to  include  it, 
they  should  also  take  into  consideration  the  problem  of  changes  in  organizational 
structure,  addressed  in  Chapter  14. 

Regarding  automatic  filing,  u>c  concur  with  the  subjects;  it  is  highly  desirable.  But 
we  would  like  to  issue  a  warning.  Most  files  are  subject-oriented.  If  the  service  cannot 
decompose  subject  line  and  also  isolate  flagwords,  then  the  utility  of  this  feature  will  be 
extremely  low.  We  believe  this  is  a  nontrivial  task,  since  the  designers  have  no  control 
over  the  formatting  and  content  of  incoming  messages;  however,  it  is  a  worthwhile 
investment,  time  permitting. 

In  the  opinions  of  the  subjects,  automated  aids  for  retrieval  are  more  useful  than 
automatic  filing.  We  agree.  Incoming  traffic  can  be  filed  explicitly  from  the  PENDING  file 
to  appropriate  subject  files.  These  messages  must  be  looked  at  anyway,  for  purposes  of 
action  assignment,  etc.  Retrieval  exhibits  the  inverse  problem.  Instead  of  being  handed  a 
message  to  put  away,  one  is  asked  to  obtain  one  put  away  earlier.  In  filing,  all  the 
essentials  are  at  hand;  with  retrieval  there  are  unknowns.  Consequently,  a  large  portion 
of  the  subject’s  time  is  spent  seeking  messages  —  especially  those  personnel  in 
administration.  Refer  to  Figs.  6-4  and  6-5.  The  retrieval  process  is  most  important  and 
here  the  computer’s  characteristics  of  speed  and  symbol  manipulation  can  be  used 
advantageously.  The  most  serviceable  algorithm  would  be  to  allow  users  to  retrieve 
based  on  the  content  of  any  message  field,  in  the  absence  of  any  prespecification.  If  one 
were  to  seriously  consider  implementing  this  algorithm,  there  should  be  a  very  careful 
study  of  cost/benefit  tradeoff  in  secondary  storage  requirements,  access  time,  and  CPU 
time.  Thus,  with  our  present  imprecise  information,  we  do  not  recommend  this  algorithm 
for  the  1977  test.  A  feasible  algorithm  for  the  1977  test  is  the  one  presented  in  this 
chapter.  /Is  a  minimum  recommendation,  we  feel  that  it  is  essential  that  subjects  be 
allowed  to  retrieve  on  originator,  date-time  range,  flagwords,  and  user-assigned  keywords. 
Users  could  retrieve  from  subject  files,  using  these  attributes,  to  satisfy  almost  all  of  their 
present  needs.  Note,  again,  the  requirement  to  parse  the  message  to  the  extent  of 
recognizing  flagwords.  If  this  cannot  be  done,  then  users  would  have  to  add  them  as 
keywords  upon  filing. 

The  specification  of  format  and  content  of  message  excerpts  was  rated  as  useful, 
although  the  distribution  of  responses  is  rather  peculiar.  When  asked  exactly  what  they 
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would  like  to  see,  most  subjects  gave  essentially  the  same  answer.  Although  w e  are 
about  to  make  an  independent  recommendation  here,  the  designers  should  consider  this 
feature  along  with  programmed  notices  (Chapter  10),  since  the  same  programming  applies 
to  both.  The  respondent s  want  to  see  the  originator,  some  part  of  the  subject, 
action/info,  precedence,  and  DTC,  in  more  or  less  that  order.  As  a  minimum  facility,  we 

recommend  this  fixed  information  without  the  ability  for  the  user  to  program  it. 

Incidentally,  we  feel  that  the  DTG  is  not  needed.  Their  constant  request  for  it  is  based  on 
present  manual  practices.  With  the  proposed  filing  system,  there  simply  isn’t  a  need  to 
remember  or  type  in  a  string  of  digits,  beyond  stating  a  DTG  range  (such  as  SEPTEMBER) 
for  retrieval  requests. 

The  stored  program  which  is  executed  with  respect  to  each  filed  message  received  a 
rating  of  useful.  Clerical  personnel  believed  this  would  reduce  their  work  load,  and  so 
rated  it  highly  desirable.  No  one  suggested  any  operations  other  than  hardcopy  and  open. 
We  did  not  present  the  concept  of  programming  with  conditionals  because  we  did  not 

believe  this  was  feasible  to  implement  within  the  time  constraints  of  the  test.  Given  the 

ease  with  which  one  can  hardcopy  or  open  either  an  entire  file  or  a  selected  subset  (see 
Chapter  7)  we  classify  the  stored  program  as  a  nice  but  nonrequired  feature. 
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7.  THE  GENERAL  FORM  OF  INSTRUCTIONS 


An  earlier  study  [Heafner  76]  investigated  several  different  man/computer  language 
forms  for  military  use.  It  also  examined  input  devices,  namely  light  pen  and 
Keyboard/function  keys.  Based  on  that  study  and  other  constraints,  it  was  our  opinion 
that  a  (mainly)  positional  language  using  keyboard/function  keys  would  be  appropriate  for 
the  1977  test.  The  intent  of  this  chapter  (and  one  question  in  Chapter  13)  is  to  verify 
that  the  proposed  communication  form  is  suitable,  and  to  check  syntax  and  vocabulary.  To 
do  this,  we  presented  example  instructions  and  asked  the  subjects  for  their  opinions.  We 
then  inquired  about  the  desired  use  of  Boolean  expressions  as  a  selection  mechanism  to 
isolate  the  access  to  specific  messages. 


7.1  THE  PROPOSED  LANGUAGE  FORM 


7.1.1  Overview  of  the  Language  Form  Presented  to  the  Subjects 


Now  let’s  talk  about  some  of  the  ways  that  we  can  access  this  information  in  the 
files.  We  have  some  examples  of  how  you  would  go  about  instructing  the  system  to  carry 
out  some  of  these  tasks.  In  particular,  some  of  the  ones  we've  illustrated  here  (Fig.  7-1) 
are  retrieval  and  file  storage  operations.  Each  line  represents  one  instruction  that  you 
would  give  to  the  computer.  The  labels  in  the  boxes  represent  function  keys  on  the 
keyboard  and  all  you  would  have  to  do  is  press  that  key.  These  would  be  fairly  common 
and  important  functions. 

For  example,  again  using  the  VISITORS  file,  suppose  you  want  to  see  all  the 
messages  m  that  file  that  were  drafted  by  J33.  Push  the  DISPLAY  key,  type  the  name  of 
the  file,  push  the  DRAFTER  key,  type  J33,  push  the  EXECUTE  key,  then  you’ll  get  a  listing 
on  your  screen  like  this  (Fig.  7-2)  of  all  the  messages  from  that  file  that  were  drafted  by 
J33.  As  another  example,  suppose  you  want  all  the  ones  in  the  VISITORS  file  whose 
subject  is  Congressman  somebody.  Push  DISPLAY,  type  VISITORS,  push  the  SUBJECT  key, 
type  CONGRESSMAN  SMITH,  and  EXECUTE,  and  you  get  those  messages  from  the 
VISITORS  file  whose  subject  contains  Congressman  Smith. 

To  delete  messages  from  the  file,  push  the  DELETE  key,  type  the  name  of  the  file, 
DRAFTER  J33,  EXECUTE;  it  would  delete  those  messages  from  the  VISITORS  file  that  were 
drafted  by  J33.  Same  thing  for  hardcopy. 

To  file  a  message,  suppose  you’re  looking  at  one  individual  message  on  your  screen 
like  this  (Fig.  I-3b)  and  you  want  to  file  this  message.  In  addition  to  those  other  retrieval 
fields  that  you  would  specify  when  setting  up  the  VISITORS  file,  you  also  will  be  interested 
in  the  drafter  field.  You  could  push  the  FILE  key,  type  the  name  of  the  file  that  you  want 
to  put  the  message  in,  push  the  DRAFTER  key,  and  EXECUTE.  If  you're  simply  filing  this 
in  the  VISITORS  file  and  want  to  file  it  the  way  all  of  the  other  messages  are  filed,  you 
wouldn't  need  this  key.  Push  FILE,  type  VISITORS,  EXECUTE  and  that’s  it,  the  message  is 
filed. 


Again,  going  back  here  (Fig.  7-2)  if  you  have  a  display  of  excerpts,  and  you  want 
to  see  message  number  two,  push  DISPLAY,  type  2,  EXECUTE  and  you  get  message  number 
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2.  If  you  have  a  list  of  message  excerpts,  again ,  and  you.  want  to  forward  some  of  them  to 
other  individuals,  open  them  on  the  messages,  then  push  the  FORWARD  key,  type  the 
message  numbers  that  you  want,  the  office  code  where  they  are  going  J311,  EXECUTE,  and 
the  J311  code  would  be  added  to  their  distribution  list  and  they  would  be  sent  to  J311  and 
automatically  added  to  his  PENDING  file. 


7.1.2  A  Question  on  the  Proposed  Language  Form 

Don’t  be  concerned  with  the  specific  examples,  but  rather  the  general  way  we 
envision  you  would  go  about  it,  having  keys  for  the  important  fixed  functions  and  then 
typing  in  the  information  that  is  variable.  I’d  like  to  get  your  comments  on  the  general 
form  of  this  kind  of  interaction  with  the  computer,  and  also  get  your  comments  on  the 
vocabulary  words  we  have  been  using. 


7.1.3  Analysis  of  Responses  to  the  Proposed  Language  Form 

There  were  few  objections  to  the  syntax.  From  the  example  keyboard  (Fig.  1-1), 
which  was  completed  only  to  the  extent  necessary  to  illustrate  the  example  instructions, 
several  recommendations  were  made  with  respect  to  vocabulary  and  with  respect  to  which 
arguments  should  be  function  keys.  Almost  everyone  suggested  OPEN  to  replace 
FORWARD.  A  few  people  suggested  slant  signs  to  replace  commas.  ORIGINATOR  and 
DTG  were  recommended  as  function  buttons,  and  DRAFTER  should  be  removed.  We  give 
an  expanded  recommendation  at  the  end  of  the  chapter. 


7.1.4  Remarks  on  the  Proposed  Language  Form 


Respondent:  It’s  understandable. 


Respondent:  I  would  have  a  button  for  originator,  but  not  drafter. 


Respondent:  They  are  reasonable  words,  I  have  no  quarrel  with  them. 


Respondent:  The  vocabulary  is  fine. 


Respondent:  Are  we  going  to  deal  with  the  keyboard  specifically  later? 


Interviewer:  Are  you  familiar  with  light  pens  or  other  pointing  devices? 
Respondent:  Yes. 


Interviewer:  I  have  a  question  later  regarding  your  preference  of  pointing 
devices  versus  function  keys. 


Respondent:  The  thing  I’m  talking  about  is  the  EXECUTE  button.  On  the 
existing  equipment  it  is  down  here  in  the  corner.  On  this  one  (Fig.  1-1)  it  is 
up  here.  /  would  see  some,  advantage  in  trying  to  arrange  it  so  it  is 
somewhere  near  or  similar  to  the  keyboards  we  have  now. 

Interviewer:  Presumably,  between  the  test  next  year  and  the  development  of 
an  operational  system,  there  will  be  some  human  factors  design  of  the 
terminal  carried  out.  There  hasn’t  been,  to  my  knowledge,  for  this  test  next 
year.  The  keyboard  that  you  see  here  (Fig.  1-1)  was  chosen,  I  believe,  from 
the  standpoint  of  reliability  and  it  has  these  keys  up  here  in  the  same 
proximity  as  this  figure.  We  could  put  any  labels  on  them  for  any  functions. 

Respondent:  I  certainly  think  that  they  ought  to  do  that  before  a  real 
operational  system.  Because  we’re  going  to  have  several  different  keyboards 
and  it  is  just  going  to  be  a  source  of  error  ...  Use  open  instead  of  forward  ... 
You  have  these  separated  by  commas;  the  existing  system  separates  them  by 
slant  signs.  In  the  changeover  that  might  be  a  source  of  error.  You  might 
want  to  consider  making  that  a  slant  sign.  It  seems  arbitrary  to  me  anyway. 
Everyone  uses  slant  signs  in  LDMX  and  a  lot  of  people  here  and  in  Washington 
and  other  places  are  familiar  with  that. 


Respondent:  Forward  —  I  would  use  open  for  this  staff. 


Respondent:  I  understand  the  idea,  and  the  words  are  fine  with  me. 


Respondent:  You  don’t  recall  or  pull  something  out  by  who  drafted  it.  Now 
originator  is  something  else  again.  As  a  suggestion,  originator  might  replace 
drafter  as  a  button.  I’d  say  open  instead  of  forward. 


Respondent:  I  think  the  function  buttons  are  mandatory  rather  than  having  to 
hunt  and  peck.  I  think  this  is  okay. 


Respondent:  Fine.  Open  up  would  probably  be  a  more  standard  form  than 
forward. 


Respondent:  I  don’t  seem  to  have  any  problem  with  the  words  that  you’ve 
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used.  And  I  like  the  minimum  amount  of  typing  that  you’ve  built  into  the 
system.  I  don’t  see  any  problem  at  all.  It’s  much  simpler  than  I  would  have 
expected  ...  Forward  is  not  a  very  descriptive  word  in  the  jargon  of  the 
Headquarters.  If  you  told  me  that’s  what  it  meant  then  I  suppose  I  could  get 
used  to  that. 

Interviewer:  I  don’t  want  to  do  that.  I  want  to  use  the  words  that  you’re 
using  now. 

Respondent:  The  term  used  in  the  Headquarters  is  open. 


Respondent:  It  makes  it  look  very  easy. 

Interviewer:  That’s  the  intent.  Is  it  a  reasonable  way  to  operate? 

Respondent:  Sure  looks  it.  I  don’t  want  a  drafter  key,  I  want  originator,  I 
want  date-time  group.  I  would  say  date-time  group  would  be  most  valuable. 


7.2  MESSAGE  ACCESS  BY  TWO  LOGICAL  CONDITIONS 


7.2.1  A  Question  on  Two-Condition  Access 

.'I 

Let’s  talk  about  some  other  kinds  of  instructions  that  will  allow  you  to  select  more 
carefully  or  more  finely  the  subset  of  messages  that  you  want  from  a  file ,  assuming  that  -j 

you  really  don’t  want  to  see  them  alL  As  an  example  (Fig.  7-3),  in  the  VISITORS  file, 
suppose  you  want  to  see  all  the  messages  that  were  drafted  by  J32  and  also  had  a 
date-time  group  in  the  month  of  May  (and  since  you  specified  that  you’d  like  a  DTG  key, 
we  can  assume  that  this  is  actually  a  key).  The  way  it  would  work  is  that  you’d  press 
HARDCOPY,  type  the  name  of  the  file,  VISITORS,  press  DRAFTER,  type  J32,  type  the  word 
AND,  push  the  DTG  key,  and  enter,  in  this  case,  a  range  for  date-time  group.  The  service 
knows  about  different  ways  of  specifying  dates  and  also  real  date-time  groups.  Now,  push 
EXECUTE.  And  what  you  would  get  is  just  those  message  headers  from  the  VISITORS  file 
corresponding  to  messages  that  were  drafted  by  J32  during  May.  As  another  example, 
suppose  you’re  interested  m  two  blocks  of  messages,  again  from  the  VISITORS  file,  but 
ones  released  by  J3  or  released  by  J3A.  You  do  it  this  way.  DISPLAY,  name  of  the  file, 

RELEASER  J3,  type  OR,  press  RELEASER,  type  J3A,  EXECUTE.  And  you  get  two  blocks  of  ^ 

message  headers  from  the  VISITORS  file:  the  ones  released  by  J3  and  the  ones  released  by 

J3A. 


We’d  like  for  you  to  rate  numerically  the  ability  to  couple  together  two  of  these 
selection  conditions  in  order  to  extract  more  precisely  the  information  you  want. 


7.2.2  Analysis  of  Responses  to  Two-condition  Access 
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Figure  7-4  thowt  the  retpontet  which  were  rated  a*  highly  dairable.  This  was  the 
uniform  opinion  of  all  subgroups. 
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7.2.3  Remarks  on  Two-Condition  Access 


Respondent;  Quite  often  I  get  requests  from  someone  who  has  lost  their 
comeback  copy  and  they  want  a  message  they  originated  last  week  sometime. 
And  we  go  through  the  file  message-by-message. 

Interviewer:  How  would  you  ask  for  that? 

Respondent:  I  would  ask  for  messages  released  by  such  and  such  an  office  or 
originator,  say,  from  the  1st  to  the  7th  of  July.  Sometimes  people  give  us 
keywords  from  the  subject. 


Respondent:  It  might  be  nice  to  have  some  default  options  here  —  the  date 
could  default  to  1  if  you  don’t  specify.  I  wrote  down  here  descriptors.  I’m 
not  a  data  processing  guy  but  I  have  used  library  systems.  It  is  a  little  bit 
similar.  What  happens  here  is  that  a  message  is  looked  at  and  receives 
several  descriptors:  three,  four,  five,  numbers  or  whatever.  This  is  useful 
when  you  want  to  go  back  and  access  something  and  you  don’t  know  exactly 
what  it  is  you  want.  And  it  is  a  little  bit  different  from  using  words  because 
words  tend  to  be  a  little  too  specific.  Is  this  going  to  be  a  capability  that  we 
have? 
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Interviewer:  What  kinds  of  descriptors  do  you  have  in  mind? 

Respondent:  Oh,  just  numbers.  I  would  say  things  that  deal  with  aircraft, 
reconnaissance. 

Interviewer:  One  of  the  things  we  were  thinking  of  is  to  allow  you  to  add 
keywords  like  the  flagwords  on  a  message,  so  that  you  could  retrieve  on  the 
basis  of  the  keywords.  That’s  what  you’re  asking  for  I  think.  Is  that 
sufficient  or  would  you  like  to  have  something  like  attribute/value  pairs  such 
as  LOCATION:  HONOLULU,  LOCATION:  NAPLES  and  then  be  able  to  retrieve 
everything  from  a  given  location? 

Respondent:  I  would  like  to  see  something  that  forces  you  to  put  appropriate 
descriptors  on  ... 

Interviewer:  Well,  "appropriate"  is  very  subjective. 

Respondent:  Yes.  The  SSICs  are  not  useful. 

Interviewer:  You  have  the  problem  of  having  either  too  many  or  too  few.  So 
you  have  to  be  judicious  in  your  choice  for  descriptors  for  your  own  use. 
We  can  provide  the  facility  for  you  to  use  keywords. 

Respondent:  All  right.  That  could  be  added  then,  and  later  used  as  a  basis  of 
retrieval. 

Interviewer:  Yes. 

Respondent:  That’s  fine.  I  think  you  really  have  to  have  that. 


Respondent:  Retrieval  is  the  big  thing.  This  will  save  us  time. 


9  Respondent:  I  really  like  that.  I  have  one  file  right  now  that  contains  750 

messages.  Is  it  amenable  to  this  system? 

Interviewer:  Yes.  And  in  a  moment  we  will  discuss  perhaps  a  more 
appropriate  access  method  for  that  file,  to  extract  a  single  message. 

#  Respondent:  I  also  like  the  ability  to  stipulate  a  time  period  for  a  message. 


7.2.4  A  Question  on  the  use  of  AND  and  OR 

What  about  the  use  of  the  words  "and"  and  ”or?“  Would  you  prefer  some  other 
punctuation? 
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7.2.5  Analysis  of  Responses  to  the  use  of  AND  and  OR 

Only  two  subjects  suggested  alternate  connectives,  which  were  comma  and  slant 
sign.  The  remainder  preferred  AND  and  OR,  and  they  preferred  to  type  them  rather  than 
use  a  valuable  function  key  for  that  purpose. 


7.3  CHAINING  LOGICAL  EXPRESSIONS  FOR  MESSAGE  ACCESS 
7.3.1  A  Question  on  Boolean  Expressions 


There  is  yet  another  way  to  more  precisely  select  the  information  you  want.  The 
idea  is  to  be  able  to  string  or  chain  these  conditions  together  in  even  more  precise  kinds  of 
search  requests.  Again,  using  the  example  of  the  VISITORS  file,  suppose  you  want  all  the 
message  headers  that  were  drafted  by  J32  with  a  date-time  group  of  May,  and  with  the 
subject  of  Congressman  Smith  or  Congressman  Jones.  Press  DISPLAY,  type  the  file  name, 
press  DRAFTER,  enter  J32,  the  DTG  of  May,  press  SUBJECT,  type  CONGRESSMAN  SMITH, 
type  OR,  press  SUBJECT,  and  type  CONGRESSMAN  JONES,  then  EXECUTE.  You  would  get 
just  those  message  headers  released  in  May,  drafted  by  J32,  and  deaUng  with  either 
Congressman  Smith  or  Congressman  Jones.  The  concept  here  is  the  ability  to  chain  these 
selection  conditions  together  in  the  precise  way  you  want  in  order  to  pick  out  just  the  one 
message  or  the  set  of  messages  that  you’re  interested  in. 

How  would  you  rate  the  capability  of  chaining  search  requests  in  this  way? 


7.3.2  Analysis  of  Responses  to  Boolean  Expressions 

Figure  7-5  shows  responses  to  the  question  on  Boolean  requests.  It  teas  rated 
desirable.  Although  the  mean  -  1.8  is  slightly  less  than  that  of  the  previous  question 
mean  =  2.1,  in  each  case  more  than  a  third  of  the  respondents  rated  these  features  a 
requirement.  Their  differences  in  responses  are  directly  related  to  their  file  sizes.  As 
might  be  expected,  there  was  a  significant  positive  correlation  between  their  ratings  on 
these  two  questions.  There  were  no  significant  differences  among  subgroups. 


7.3.3  Remarks  on  Boolean  Expressions 


Respondent:  Now  that  would  be  very  desirable.  It’s  not  a  necessary 
requirement  but  it  is  very  desirable.  We  can’t  do  that  now,  by  subject.  If 
we  don’t  have  a  date-time  group  or  a  control  number,  we’re  in  trouble. 

Interviewer:  We  re  trying  to  get  away  from  the  numbers  because  something 
like  a  subject  string  makes  more  sense  to  people  than  a  string  of  digits.  In 
the  service  we’ve  outlined,  you  can  reference  messages  without  ever  having 
to  enter  a  specific  DTG. 

Respondent:  In  fact,  we  had  that  problem  last  week.  There  were  two 


messages  the  General  wanted  to  see  and  we  had  no  idea  what  the  date-time 
groups  were. 

Interviewer:  Presumbly  with  the  personal  files  organized  the  way  you  want 
them  and  the  reference  mechanism  we’ve  talked  about,  you  wouldn't  ever 
have  to  worry  about  a  date-time  group. 


Respondent:  /  want  the  facility  to  input  a  string  of  values  separated  hy 
commas ,  where  they  have  the  same  attribute,  for  example,  RELEASER  J  l,J2. 


Respondent:  That’s  fine.  That’s  the  basic  Boolean  problem. 


Respondent:  That  gets  right  down  to  the  very  message  you  want.  I  can  see 
that  would  be  very  useful. 


Respondent:  That  gets  a  broad  field  down  to  something  really  narrow.  I’d  say 
a  plus  three  because  I  know  some  "witch  hunts"  I’ve  gone  through  trying  to 
find  a  message  on  a  subject. 


Respondent:  I  think  that  would  be  a  plus  three,  especially  with  large  files. 
Our  Thailand  file  is  four  manila  folders.  If  you  just  give  a  date-time  group  in 
a  certain  area  you’d  get  thousands  of  messages.  I  think  it  is  very  important 
to  get  down  to  the  very  specifics. 

Interviewer:  Do  you  think  that  you  could  easily  identify  the  message  you 
wanted  using  this  feature? 

Respondent:  Yes.  In  that  particular  example,  if  you  had  Thailand,  J--,  DTG 
area,  and  flagwords  such  as  air  movements,  just  that,  for  example,  would 
knock  it  down  considerably. 

7.4  UNSOLICITED  REMARKS  ON  LANGUAGE  FORM 

Respondent:  Eel's  talk  about  language  —  the  language  of  your  system.  It 
should  be  the  plainest,  simplest,  honest  English. 

Interviewer:  We  showed  you  some  examples  earlier. 

Respondent:  Yes.  You  have  achieved  that  in  many  respects.  If  you  retain 


59 


that  same  capability,  and  not  let  the  programmers  start  telling  us  we’ve  got  to 
put  one  X  instead  of  FILE.  FILE  you  understand,  one  X  you  don’t,  and  to  the 
users  it’s  the  most  horrible  part  of  an  automated  system. 

Interviewer:  I  understand.  When  we  talked  with  military  people  in 
Washington,  we  spent  most  of  our  time  talking  about  the  vocabulary  and 
syntax  of  commands. 

Respondent:  You’re  never  going  to  get  all  the  action  people  so  versed  in  a 
computer  vocabulary  that  they  can  interact  with  it.  There  is  constant  change 
over;  you  cannot  train  the  entire  military  to  "one  X.”  It  just  can’t  be  done. 
The  word  FILE  should  mean  file  and  it  should  be  in  plain  English.  Had  we 
done  this  years  ago  in  planning,  in  programming  computers,  we’d  be  far 
ahead. 

Interviewer:  Our  problem  is  that  we  don’t  know  what  you  want.  We  make  our 
best  guess  and  then  come  and  talk  with  you  about  it,  but  it  needs  iteration. 

Respondent:  Our  problem  is  that  they’ll  come  to  me  and  say  "What  do  you 
want"  and  I’ll  tell  them  and  then  they’ll  say  "I  can’t  give  you  that."  So  why  are 
you  asking  me  if  you  can’t  give  it  to  me?  "We  can  only  give  it  to  you  in  this 
type  of  vocabulary.  Hit  the  caret  or  this  inverted  Y  and  it  will  do  this."  They 
are  very  interested  in  finding  out  what  you  want  so  that  they  can  tell  you 
that  they  can’t  give  it  to  you. 

Interviewer:  I’m  not  directly  associated  with  any  of  the  three  current 
candidate  systems,  but  my  understanding  is  that  each  of  them  can  provide  the 
kind  of  syntax  and  vocabulary  that  you  want.  And  that’s  why  we’re  here,  to 
get  your  recommendations  to  give  to  them. 

Respondent:  I  just  want  to  emphasize,  plain,  simple  English.  NO  or  YES, 
EXECUTE,  RETURN,  GIVE  IT  BACK,  things  that  even  the  "Kentucky  plowboy"  can 
read  and  understand.  Then  we’re  not  going  to  "screw  it  up." 

Interviewer:  How  about  abbreviations? 

Respondent:  He  very  careful  because  abbreviations  can  get  you  in  deep 
trouble  in  the  joint  arena,  because  each  of  the  services  has  their  oum 
abbreviations,  and  they  mean  different  things. 

Interviewer:  We  discovered  that  in  Washington,  they  have  the  WASH-MlC 
[WASH-MIC  71],  this  big  thick  book  of  military  acronyms,  but  it  is  inconsistent 
with  their  use  of  abbreviations  and  acroynms.  The  book  is  not  up  to  date. 

Respondent:  It  is  an  extremely  beautiful  way  to  get  into  trouble. 

Interviewer:  Let  me  suggest  something  and  see  how  you  react  to  it.  You 
could  indeed  use  abbreviations  and  acronyms  on  input.  Where  we  echo  or 
reflect  what  you  are  typing  in,  we  would  spell  it  out.  That  is,  the  output  from 
the  service  would  never  be  abbreviated.  You  could  save  yourself  the  typing 
on  input.  You  get  the  positive  feedback  to  see  that  it  is  in  fact  interpreted 
exactly  as  you  intended.  Would  that  be  a  decent  way  to  do  it? 


Respondent:  Oh,  sure.  There  has  to  be  some  standard  abbreviations  and 
acronyms.  The  word  CHOP  is  generally  found  in  the  joint  arena  or  in  the 
Navy.  The  Army  doesn’t  Know  what  a  chop  is,  except  what  you  do  to  meat. 
Usually,  in  the  Army,  it’s  concurrence  or  nonconcurrence. 

So,  you  get  a  guy  working  in  the  Army  arena  and  he  uses  the 
abbreviation  OPS,  which  is  operations.  And  you  get  a  guy  from  the  Navy 
using  the  same  thing  and  it  has  a  different  meaning.  And  it  just  doesn’t 
match.  Every  action  officer  who  gets  into  the  joint  arena  finds  himself  in 
deep  trouble  in  10  days.  And  he  learns,  and  he  never  again  uses  any 
abbreviations  that  can  possibly,  under  any  circumstances,  be  misconstrued. 

Interviewer:  That’s  probably  most  all  of  them. 

Respondent:  That’s  nearly  all  of  them.  U.S.,  when  it’s  in  capital  letters  can 
rarely  be  misconstrued. 

Interviewer:  Right  now  you  have  a  lot  of  abbreviations,  like  the  security 
redundancy  code.  You’ll  enter  0000  for  immediate.  Would  you  expect  to 
spell  out  immediate? 

Respondent:  You’re  talking  about  messages,  which  of  course  have  to  have 
brevity.  I’m  speaking  of  primary  memorandums,  letters,  and  things  like  this. 
Messages  have  to  have  this. 

Interviewer:  So,  we  should  stick  with  the  standard  abbreviations  for  message 
processing? 

Respondent:  I  guess  you  can’t  do  away  with  those.  In  the  text  is  where  the 
confusion  is  liable  to  arise. 

Interviewer:  The  text  is  not  interpreted  by  the  service. 

Respondent:  I  was  just  reacting  rather  vividly  to  a  question  on  the  use  of 
abbreviations  ...  I  wrote  a  message  to  JCS,  I  retrieve  it  from  the  archives  or 
my  files.  Now  I  want  that  message  harden  pied,  fill  I  need  to  do  is  hit  the 
II  flRDCOPY. 

Interviewer:  Everyone  we’ve  talked  with  wants  contextual  defaults  where  you 
don’t  have  to  give  the  identification  because  it  is  obvious  that  it’s  the 
message  you’re  looking  at. 

Respondent:  That’s  right.  The  same  with  the  alert.  If  I  say  II flRDCOPY,  I 
mean  the  one  I’m  alerted  to,  because  I  don’t  want  it  printed  out  on  my  reader, 

I  may  have  other  things  I’m  looking  at. 

7.5  INTERPRETATIONS  AND  RECOMMENDATIONS 

We  recommend  providing  fioolean  expressions  for  message  selection.  It  was  highly 
rated  by  those  subjects,  relative  to  their  rating  of  other  features.  Message  retrieval  is 
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one  of  their  biggest  problems,  and  in  this  way  an  automated  service  can  greatly  help.  The 
grouping  or  nesting  problem  was  not  discussed,  nor  was  NOT.  We  felt  that  with  the 
limited  time  we  were  allotted  with  each  person,  the  time  could  be  better  spent  discussing 
other  parts  of  the  service.  We  believe  that  these  people  would  have  no  trouble 
understanding  a  Venn  diagram  and  accepting  the  use  of  parentheses,  where  needed. 

/Ij  a  very  minimum  capability,  toe  recommend  a  two-condition  selcc.or  which  allows 
the  user  to  choose  from  the  following  message  fields:  date-time  range,  originator, 
flagwords,  and  keywords. 

The  right  syntax  and  vocabulary  are  crucial  to  the  military’s  adoption  of  the  service. 
We  included  some  remarks  on  this  by  one  respondent.  He  was  not  alone  in  this  attitude. 
The  form  proposed  resulted  from  the  earlier  study  in  Washington  and  was  well  received 
on  Oahu,  with  few  exceptions  in  form  (see  the  chop  list  organization  in  Chapter  11). 
Vocabulary  differs  somewhat  from  that  used  in  Washington,  so  below  we  have  given  their 
suggestions  for  function  button  labels.  These  functions  are  explained  throughout  the 
report. 

Suggested  labels  for  function  buttons: 


DISPLAY 

FILE 

HARDCOPY 

REFERENCES 

DRAFT 

OPEN 

SEND  FOR  CHOP 
CHOP 

RETURN  TO  DRAFTER 
REASSIGN  ACTION 
ORIGINATOR 
DTG 

NEXT  MESSAGE 
PREVIOUS  MESSAGE 
SAVE  MESSAGE  AND  INTERRUPT 
RETURN  TO  PREVIOUS  MESSAGE 


8.  FILE  ARCHIVAL  PRINCIPLES  AND  PRACTICES 


Archiving  messages  serves  two  purposes  in  the  proposed  service.  From  the  user’s 
viewpoint,  in  order  to  be  serviceable,  file  sizes  must  be  kept  within  manageable  limits. 
From  the  design  and  cost  points  of  view,  archiving  reduces  the  amount  of  disk  storage 
required.  We  began  by  posing  two  questions  concerning  both  automatic  and  user-initiated 
archiving.  The  attempt  was  to  get  an  idea  of  the  amount  of  on-line  storage  required  and 
determine  how  it  might  differ  from  the  sizes  of  present  hardcopy  files.  We  were  also 
concerned  with  retrieval  time  requirements.  The  subjects  soon  added  two  more  questions 
to  our  list  involving  the  exemption  of  messages  from  archive  (similar  to  DON’T  ARCHIVE  in 
TENEX  [Myer  73]),  and  precedence  requests.  Let’s  take  a  look. 


8.1  AUTOMATIC  ARCHIVAL 

8.1.1  A  Question  on  Automatic  Archival 


We  mentioned  something  about  file  archiving  and  you  had  some  questions  about  it 
earlier.  There  are  really  two  reasons.  From  your  point  of  view  you  want  to  reduce  the 
clutter  in  your  files.  F rom  our  point  of  view  we  want  to  back  things  up  on  magnetic  tape 
(which  is  what  the  archive  will  consist  of)  because  it’s  much  much  cheaper  than  the  on-line 
storage.  The  access  time  from  your  point  of  view  is  that  if  it’s  on-line  you  can  access  a 
message  or  an  excerpt  of  a  message  in  a  couple  of  seconds  and  if  it  is  on  magnetic  tape  it 
may  take  several  minutes  up  to  perhaps  a  half  an  hour,  depending  on  the  number  of 
concurrent  requests  from  archives.  So,  in  order  to  minimize  the  amount  of  on-line  storage 
and  therefore  the  cost,  one  feature  that  we  could  provide  is  the  following:  You  recall  here 
(Fig.  6-1)  we  have  a  file  storage  time  block  on  the  file  header  to  indicate  the  time  period, 
such  as  30  days.  So  every  30  days  for  that  file,  the  system  would  come  along  and  look  at 
all  of  the  messages  in  that  file,  and  all  of  those  that  had  not  been  accessed  by  you  or  by 
someone  else  in  that  time  period  would  be  automatically  archived  on  your  personal  archive 
file  associated  with  that  file.  Then,  the  copies  would  be  deleted  from  your  on-line  file, 
automatically.  How  would  you  rate  that  feature? 


8.1.2  Analysis  of  Responses  to  Automatic  Archival 

Figure  8-1  illustrates  the  responses.  It  was  rated  highly  desirable,  with  the  most 
common  response  being  a  requirement.  There  was  no  significant  differences  among  the 
subgroups,  but  there  was  a  strong  correlation  between  their  responses  here  and  their 
ratings  of  the  general  file  system  organization. 
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Fig.  8-1  Ratings  for  Automatic  Archival 


8.1.3  Remarks  on  Automatic  Archival 


Respondent:  Plus  three.  It’s  something  that  has  to  be  done.  We  have  been 
holding  30  dayi.  With  the  time  it  mould  take  you  to  retrieve  it  from  the 
archive,  probably  15  dayi  would  be  fine. 


Respondent:  How  will  I  know,  when  I  want  to  call  for  a  message,  whether  it  is 
on  disk  or  tape? 

Interviewer:  You  could  have  special  independent  archives  associated  with  each 
of  your  personal  files.  You  could  display  excerpts  of  your  PENDING  ARCHIVE 
file,  for  example,  instead  of  your  PENDING  file.  When  you  ask  for  an  archived 
message,  using  the  same  instruction  form  you  use  for  a  message  in  your 
active  files,  the  service  will  give  you  an  estimate  of  how  long  the  retrieval  will 
take.  The  amount  of  time  it  takes  depends  upon  the  number  of  concurrent 
requests,  but  it  shouldn’t  ever  take  more  than  an  hour. 

Respondent:  The  30  days  is  longer  than  I  need.  I  could  get  by  with  about  15 
days. 


Respondent:  What  about  TDY  or  leave?  How  do  you  get  back  the  onet  you 
haven't  teen? 

Interviewer:  A  copy  of  all  your  incoming  traffic  will  go  in  your  PENDING  file. 
Those  messages  that  have  arrived  since  you  last  displayed  the  file  will  be 
flagged  in  some  way  so  that  you’ll  know  they  are  new.  And  if  you  haven’t 
ever  accessed  a  message,  it  won’t  be  archived.  So,  all  you  have  to  do  is 
display  your  PENDING  file. 


Respondent:  /  would  give  it  a  sequence  date.  This  business  of  looking  at  it 
or  not  looking  at  it  doesn’t  really  jell  that  well,  because  you  may  look  at 
something  three  or  four  times  and  then  never  need  it.  Or  you  may  not  look 
at  another  message  and  then  need  it  on  the  31st  day. 

Interviewer:  Should  it  prompt  you  and  say  “I’m  about  to  archive  these 
messages,  is  it  okay?" 

Respondent:  I  shouldn’t  think  so.  As  long  as  you  are  aware  that  every  60 
days  this  particular  file  is  going  to  be  cleaned  out. 


Respondent:  The  longest  I  ever  keep  any  message  is  a  month.  And  basically,  I 
keep  a  message  one  day.  My  desk  is  real-time;  we  are  not  a  storage  facility. 


Respondent:  No,  that’s  too  often, 
interviewer:  What  time  would  you  choose? 

Respondent:  I’d  say  once  a  year.  Because  that’s  why  you  put  messages  in 
files,  to  be  able  to  find  them  when  you  need  them.  The  business  we’re  in, 
frequently,  messages  will  be  needed  that  are  5,  6  months,  a  year,  or  two 
years  old.  And  the  great  utility  of  the  files  is  to  be  able  to  go  back  and  get 
that  piece  of  paper.  I  think  you  really  have  to  have  that  —  still  put  together 
under  a  particular  subject  as  opposed  to  having  to  go  back  and  get  it  off  the 
LDMX  archives. 

Interviewer:  When  you  go  back  and  get  something  that  is  6  months  old,  a  year 
old,  what  are  the  time  constraints  in  retrieving  the  message?  Do  you  really 
need  it  in  seconds  versus  minutes? 

Respondent:  Oh  yes. 

Interviewer:  Fifteen  minutes  would  not  be  adequate? 

Respondent:  No.  That’s  not  responsive. 


Respondent:  Some  files  could  be  archived  after  10  days,  others  would  be 
needed  for  a  month  or  longer. 


Respondent:  Right  now  we  have  hardcopy  messages  in  our  files  that  are  years 
and  years  old.  But  they  give  a  chronology.  We  need  that.  So  we  have 
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determined  that  this  overall  file  will  be  maintained.  Every  time  you  pull  out 
the  drawer,  it’s  there  to  remind  you.  When  you  run  out  of  drawer  space,  you 
do  away  with  the  lesser  important  files.  You  don’t  have,  the  way  I  visualize 
it,  a  purge  system  such  as  this,  in  this  system.  You,  unknowingly,  are  going 
to  create  more  and  more  reels  of  tape. 

Interviewer:  You  can  purge  from  your  archive  files  and  from  your  active  files. 
Respondent:  What’s  the  impetus  to  do  this? 

Interviewer:  To  purge  something  from  your  on-line  files,  you  want  to  reduce 
the  clutter.  For  archived  files,  there  is  less  impetus.  I  don’t  know  how  you 
might  promote  that.  It’s  a  good  idea.  Perhaps  some  policy. 

Respondent:  Perhaps  every  two  or  three  years  when  you  are  leaving.  Because 
the  guy  coming  in,  in  all  probability,  doesn’t  have  the  knowledge  to  do  that, 
lie  will  start  his  own  archive  files  and  leave  the  old  one  going. 


Respondent:  I  think  an  arbitrary  time  period  would  be  good.  If  you  were  to 
leave  it  to  the  individual  action  officer  to  clean  out  his  files,  I  think  you  might 
have  some  problems.  Of  course,  when  we  talk  about  files,  I  keep  thinking  of 
perhaps  thick  files  /  have,  maybe  a  small  portion  of  which  are  messages,  and 
this  keeps  bothering  me  because  a  good  portion  of  mine  are  memos  both  for 
record  and  not  for  record. 


8.2  RETRIEVAL  BASED  ON  PRECEDENCE  OF  THE  REQUEST 

The  order  of  retrieval  from  archive,  based  upon  the  priority  of  the  request,  was  not 
included  as  a  question.  However,  after  several  requests  for  this  feature,  the  remainder  of 
the  subjects  were  asked  to  comment  on  the  ability  of  making  priority  requests.  It  was 
rated  highly  desirable. 


8.2.1  Remarks  on  Priority  Requests 


Respondent:  If  there  are  lots  of  people  on-line  that  are  requesting  information 
from  the  archives,  is  there  any  way  to  have  a  priority  execute  button  or 
immediate  button  to  retrieve?  Say,  the  Ceneral  has  to  have  a  copy  of  this 
right  now,  he  is  talking  to  IPashington  on  the  phone,  but  it  is  in  the  archives. 
Do  we  have  to  make  him  wait  an  hour  and  hold  that  question? 

Interviewer:  You  should  not  have  to.  No  one  else  has  brought  that  up,  but  I 
guess  you  could  use  the  same  four  levels  you  assign  to  messages,  and  enter  a 
Z,  0,  P,  or  R  along  with  tha  request.  That’s  one  of  those  things  that  could  be 
abused,  of  course. 


Respondent:  Oh  yes. 


Interviewer:  It  becomes  an  administrative  question.  We  can  recommend  the 
incorporation  of  that  feature,  but  then  you  have  the  administration  problem  of 
seeing  that  it  is  not  abused. 


Respondent:  You  have  a  certain  code  that  the  machine  knows.  The  machine 
could  only  accept  certain  precedence  requests  from  certain  codes. 

Interviewer:  Yes.  How  would  you  rate  this  feature  that  you’ve  just 
described? 

Respondent:  Plus  three. 


Respondent:  That  would  probably  be  the  best  way  —  based  on  precedence,  if 
stiff  requirements  were  levied  on  the  use  of  the  priority  system. 


Respondent:  Yes,  I  would  like  that  function. 


Respondent:  Yes,  definitely. 


Respondent:  Most  of  the  time  we  have  some  forewarning.  But  sometimes  we 
get,  "Hey,  remember  that  message.  The  CINC  wants  an  answer  now."  So,  we 
have  to  have  an  answer  in  half  an  hour.  Well,  if  I  have  to  wait  an  hour  to  get 
the  message  then  I’m  shot  already. 


8.3  EXEMPTING  MESSAGES  FROM  ARCHIVE 

No  question  was  planned  for  the  subjects  regarding  the  exempting  of  messages  from 
deletion  from  active  files.  However,  after  several  requests  for  this  feature,  the  remaining 
subjects  were  asked  to  rate  the  utility  of  being  able  to  mark  individual  messages  to  remain 
in  active  files. 


8.3.1  Analysis  of  Responses  to  Message  Exempting 

Seven  subjects  rated  the  feature  desirable.  Their  mean  =  1.9,  std.  dev.  »  0.9,  and 
mode  -  1. 


8.3.2  Remarks  on  Maintaining  Messages  indefinitely  on  Active  Files 


Respondent:  Well,  if  it  would  be  possible  to  identify  a  certain  message  as 


some  historical  message,  and  tag  it  in  some  way  so  that  you  could  save  it, 
then  you  could  have  the  system  comb  through  there  and  clean  up  all  the 
others  and  toss  them  out. 


Respondent:  From  the  point  of  view  of  its  utility  to  me,  in  keeping  my  files 
cleared  out?  I  was  wondering  if  it  might  not  be  easier  and  just  as  acceptable 
to  put  an  automatic,  say  30  days,  limit  on  all  messages,  and  have  them 
automatically  put  into  the  archive  unless  the  user  specified  through  some 
code  to  save  them  for  an  indefinite  period,  in  which  case  they  would  not  be 
archived  until  the  user  released  them. 


8.4  EXPLICIT  ARCHIVAL 


8.4.1  A  Question  on  Explicit  User-Instructed  Archiving 


Another  feature  is  that  you  can  explicitly  file  them  away  yourself  in  the  archives , 
and  you  might  do  that  on  the  basis  of  an  entire  file  or  specific  entries  in  a  file.  Hou/ 
would  you  tend  to  do  this ? 


8.4.2  Analysis  of  Responses  on  Explicit  Archiving 

Nineteen  subjects  responded.  Eight  would  prefer  to  archive  individual  entries, 
three  would  archive  entire  files,  and  8  want  both  options.  Enlisted  personnel  in 
administration  differed  significantly  from  the  remaining  subgroups  in  that  they  would  only 
archive  file  entries. 


8.4.3  Remarks  on  Explicit  Archiving 


Respondent:  I  would  say  the  whole  file.  I  would  also  want  to  be  able  to  clean 
up  my  archive  file,  say,  every  six  months. 


Respondent:  We  would  archive  by  time  period  if  it  is  something  that  is  a 
day-to-day  activity,  to  clean  it  out,  just  as  we  do  in  some  of  our  ongoing  files. 
You  should  also  have  the  ability  to  archive  the  whole  file  —  the  typhoon  is 
over.  I  suppose  that  if  you  initially  thought  that  a  problem  was  going  to  be 
short-termed,  and  it  turned  out  to  be  long-termed,  then  you  would  want  the 
ability  to  archive  certain  messages  from  the  file. 


Respondent:  I’d  have  to  go  both  ways.  For  example,  with  aircraft  movements, 


V  *  V«  l  W ’."V  T  V  V  V’  <*  J  W  -■  ^  -j  »■.  f  7  IT-.'  t^t- 7 i.~  •  v  ■ 


W  "V  -  T 


68 


once  the  event  is  over  we  throw  away  the  messages.  We  may  get  notice  that 
a  Marine  attack  squadron  is  going  to  move  back  to  El  Toro,  California.  We  get 
messages  15  or  20  days  ahead  of  time.  We  hold  them.  As  soon  as  those 
aircraft  move  15  or  20  days  later,  we’ll  watch  the  traffic  and  see  that  the 
squadron  is  back  on  the  West  Coast,  then  I’ll  throw  them  away. 

Interviewer:  Would  it  be  useful  to  do  the  following?  In  the  file  header  we 
allowed  you  to  specify  the  archival  period.  Another  way  we  could  do  that  is 
to  allow  you  to  tag  specific  messages  with  an  archive  or  delete  time.  For 
example,  if  a  squadron  is  moving  to  El  Toro  in  20  days,  and  you  know  you 
want  to  keep  those  messages  for  20  days  and  then  throw  them  away,  then 
you  could  tag  those  messages  in  the  file  and  say  archive  or  delete  after  20  or 
30  days.  That  is,  you  could  tag  it  at  the  time  you  were  thinking  about  it 
rather  that  having  to  come  back  3  weeks  later  to  clean  it  up. 

Respondent:  I  don’t  want  to  do  that  because  they’ll  say  "we’re  going  to  delay 
this  move  for  11  days  but  everything  else  pertains,  route  of  flight,  etc.”  I’ve 
entered  a  date  that  says  get  rid  of  this  message  20  May  because  they’re 
going  to  move  on  the  19th.  And  now  they  have  delayed  for  11  days.  Now, 
the  General  comes  in  and  asks  if  they  are  going  to  stop  in  Hawaii  for  fuel  or 
refuel  at  Midway  Island.  And  the  message  is  gone. 


8.5  INTERPRETATIONS  AND  RECOMMENDATIONS 

Many  of  the  archival  features  will  depend  upon  the  amount  of  disk  storage  available 
for  the  1977  test,  and  the  responsiveness  of  the  service  in  retrieving  from  tape.  Message 
traffic  and  other  variables  can  probably  be  estimated  fairly  accurately.  Longevity  of 
messages  on  active  files  depends  upon  retrieval  responsiveness,  as  was  indicated  by 
perhaps  half  a  dozen  respondents  who  thought  they  could,  with  this  service,  reduce  their 
present  active  file  sizes.  In  our  estimation,  there  will  have  to  be  ad  hoc  policy  established 
to  govern  on-line  storage  time  for  messages,  and  precedence  retrieval  requests.  So,  what 
can  we  recommend  that  will  be  useful  to  the  designers?  We  recommend  the  following 
capabilities.  Their  use  should  be  governed  by  J3  policy.  Provide  the  time  slot  in  the  file 
header  for  the  user  to  specify  minimal  archival  period.  If  users  are  not  to  maintain 
parallel  hardcopy  files,  then  precedence  retrieval,  we  feel,  is  necessary.  Tagging 
messages  to  exempt  is  necessary  for  some  users  when  the  alternatives  are  considered  (i.e., 
hardcopy  files  or  on-line  files  with  extremely  long  archival  periods).  We  would  not 
recommend  tagging  on  a  file  basis.  Explicit  archival  (of  at  least  messages)  is 
recommended;  it  will  help  the  user  and  conserve  space. 

Recording  read/write  dates  would  seem  a  good  idea.  Recall  that  one  respondent 
raised  the  question  of  losing  (archiving)  newly  arrived  messages  while  on  leave. 
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9.  ANNOTATION  CAPABILITIES  AND  CONTROLS 

Most  everyone  makes  notes.  Communication  is  the  very  essence  of  the  planned 
service.  So,  many  questions  were  included  to  determine  where  and  when  annotation 
capabilities  would  be  most  useful.  Sometimes  one  enters  reminders  to  himself,  sometimes 
questions  for  others.  Thus,  we  must  also  address  the  question  of  access  to  comments. 
Let  us  proceed. 

9.1  THE  POINT  PAPER 


9.1.1  A  Question  on  On-Line  Point  Papers 

We  have  a  number  of  forms  of  comments  that  one  can  make  and  I'd  like  to  get  your 
numerical  rating  on  which  would  be  useful  and  which  wouldn't.  The  first  is  a  point  paper. 
In  drafting  a  message,  if  it's  a  long  message,  you  may  prepare  a  point  paper,  and  right 
now  that's  a  hardcopy  that  travels  around  with  the  draft.  We  can  allow  you  to  enter  that 
on-line  and  send  it  around  coupled  to  the  message  in  the  draft  review  process.  How  would 
you  rate  that? 

9.1.2  Analysis  of  Responses  to  the  Point  Paper 

The  most  appropriate  figure  (Fig.  9-1)  to  illustrate  point  paper  responses  is  the 
diagram  showing  all  except  enlisted  personnel  in  administration.  Figure  9-1  indicates  that 
the  on-line  point  paper  is  highly  desirable.  Considering  all  subgroups,  it  was  still  highly 
desirable  (mean  =  2.4).  The  enlisted  administration  personnel  also  rated  in  highly 
desirable  (mean  =  2.0)  but  they  were  excluded  from  Fig.  9-1  (p.  75)  because  of  the  lack 
of  messages  originated  by  them. 

9.1.3  Remarks  on  the  Point  Paper 

Respondent:  That’s  absolutely  necessary  to  me.  Many,  many  times  I’m  writing 
a  message  that  is  very  short  and  cryptic,  yet  carries  an  immense  amount  of 
background.  A  guy  for  chop  or  release  has  to  have  that  background.  So  I 
have  to  write  a  separate,  much  more  detailed  memorandum,  with  references. 

Interviewer:  You  also  reference  in  the  briefing  memo?  Is  there  a  standard 
form? 

Respondent:  No.  It’s  just  a  memorandum  telling  why  I’m  doing  something.  I 
add  the  references  just  below.  Therefore,  the  man  who  is  reviewing  it  has 
my  rationale  for  doing  this.  /Inything  that  I  reference  in  the  message.  I'll 
have  to  show  him  because  he  is  going  to  be  interested  in  that.  Now,  how  can 
we  work  that  into  your  system?  I've  fust  explained  something  that  almost 
invariably  occurs.  /  rarely  will  send  anything  to  the  boss  that  I  don't  have 
references  as  a  part  of  that  overall  package,  so  he  doesn’t  have  to  come  back 
and  say  "what  did  Fleet  say  about  this?” 


Interviewer:  These  are  in  addition  to  the  ones  in  the  message  itself? 

Respondent:  They  may  or  may  not  be.  I  may  have  a  comment  going  to  JCS  in 
response  to  their  asking  us  for  information.  And  all  I  want  to  do  is  send  JCS 
that  information.  I’m  not  referencing  Fleet’s  input  in  the  message  because 
JCS  doesn’t  want  that.  They  are  interested  in  what  CINCPAC  says.  I  only 
reference,  in  my  outgoing  message,  "JCS  Request."  But,  I  have  gone  out,  to  get 
my  position  for  CINCPAC,  to  all  the  components,  or  necessary  agencies.  I 
want  to  know  what  they  said  because  it’s  on  what  they  said  and  what  I  think 
as  to  how  my  message  is  going  to  read.  I’ve  gone  to  the  components  and  I’ve 
summarized  their  comments  in  the  facing  message.  But  I  don’t  want  to  go 
through  the  whole  drill  of  saying  "CSG  liked  it,  Fleet  was  ecstatic  about  it, 
PACAF  —  eh  about  it.”  I’ve  got  to  put  those  down  there  because  the  releaser 
wants  to  read  what  they  have  to  say.  He  wants  to  make  up  his  own  mind 
what  the  feeling  is,  to  be  sure  that  I  have  encapsulated  it,  that  I’m  portraying 
CINCPAC’s  position. 

It  is  the  same  thing  within  the  staff.  If  I  have  a  message  that  I  am 
staffing,  I  have  gone  to  the  J2,  3,  4,  and  5,  and  I  have  developed  the  staff’s 
position.  Then,  I  want  to  say  the  staff’s  position  is  this.  But  I  don’t  want  to 
summarize  each  of  those,  I  want  to  hand  them  to  the  releaser  underneath.  So 
he  says,  "I  wonder  what  J--  said  about  that."  And  he  might  shoot  it  back  to  me 
saying  "justify  why  you’ve  done  this.”  You  get  into  interplay  within  the  staff. 
Now  you  do  the  same  thing  within  J3.  And  the  same  thing  within  J3-.  I  might 
go  to  Reconnaissance,  AW,  OPSECT,  Air,  Ground,  or  whatever  to  get  their 
feelings  for  it.  And  I  encapsulate  and  put  it  all  in  my  message  or  my  position. 

/  may  not  always  be  talking  about  a  message.  I  may  be  talking  about 
a  memorandum  going  to  the  /Idmiral.  How  do  I  handle  those?  Is  that  part 
of  this  system?  I  doubt  it,  you’re  talking  about  messages  incoming  and 
outgoing.  You’re  not  talking  about  intra-correspondence. 

Interviewer:  As  a  matter  of  fact,  we’re  going  to  do  that.  A  little  later  I  want 
to  talk  with  you  about  both  formal  and  informal  intra-correspondence. 

Respondent:  Thai’s  almost  more  of  my  work  than  outgoing  messages,  because 
I  spend  707,  of  my  time  doing  intra-correspondence  work,  reviewing  an  op. 
plan  that  comes  from  J5.  They  want  to  know,  from  an  operations  standpoint, 
whether  it  is  any  good.  Then,  I,  in  turn,  send  it  out  to  people  within  J3- 
saying  "What  do  you  think?"  What  I  have  is  the  lead  to  put  together  J3-’s 
position.  So,  I’m  working  intrastaff.  I’m  not  talking  about  any  message.  My 
final  copy  will  be  a  memorandum  to  the  J3,  perhaps,  or  a  memorandum  for 
the  J3  to  sign  to  the  J5  saying  "we  like  your  op  plan,  it  works."  I’m  bringing 
this  up  at  this  point  because  I  want  to  he  sure  that  you  guys  can  build 
something  that  we  can  use  within  the  Headquarters,  not  necessarily  between 
us  and  some  distant  point. 

Interviewer:  Let  me  mention  the  kinds  of  things,  in  addition  to  the  formal 
message  service,  that  we  were  contemplating,  and  then  we’ll  talk  about  them 
in  more  detail  a  little  later.  One  form  is  a  pro  forma  message  form.  Another 
is  in-house  record  communications,  just  like  the  memorandum  you’ve  been 


talking  about  —  office  memos  or  any  kinds  of  forms  that  you  may  work  with. 
Another  is  informal  traffic,  where  there  is  no  accountability.  It’s  more  like  a 
phone  call,  but  secure.  Yet  another  is  linking  directly  from  terminal  to 
terminal,  again  like  a  phone  conversation.  So,  those  are  some  of  the  things 
we’ll  be  talking  about  a  little  later  on. 


Respondent:  Okay,  that  sounds  great.  Does  that  include  an  MFR  —  memo  for 
record? 

Interviewer:  It  could  include  any  text  that  you  want  to  type  in.  It  wouldn’t 
apply  to  large,  existing  documents  that  were  not  already  on-line. 

Respondent:  Anything  that’s  prepared  at  the  time  to  go  out  with  it.  Could 
you  store  the  point  paper  in  a  personal  file? 

Interviewer:  We  could  probably  treat  it  as  a  comment  to  a  message  and  keep 
it. 

Respondent:  Great.  That’s  a  plus  three. 


Respondent:  How  would  I  display  it? 

Interviewer:  It  could  either  be  treated  as  a  field  of  the  message,  but  it  really 
isn’t,  or  you  could  ask  for  it  explicitly. 

Respondent:  I  like  the  feature  of  being  able  to  see  it  on  the  CRT.  A  plus  two. 

Interviewer:  When  the  message  is  released,  what  should  we  do  with  the  point 
paper?  Should  it  be  discarded  or  saved  with  the  drafter’s  comback  copy,  or 
what? 

Respondent:  It  should  be  fileable.  It  should  be  filed  with  the  comeback 
copies  to  the  internal  distribution  list. 


Respondent:  No  question  about  it—  plus  three. 
9.2  OVERALL  COMMENTS  ON  THE  MESSAGE  DRAFT 


9.2.1  A  Question  on  Commenting  the  Draft  Message 

Again,  with  draft  messages,  you  as  a  drafter  may  want  to  comment  for  those  who 
may  chop  a  message.  They  may  want  to  send  remarks  back  to  you  in  addition  to  their 
ability  to  edit  the  copy  that  you’re  sending  them.  There  are  two  forms  in  which  comments 
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could  appear.  One  would  allow  a  place  at  either  the  top  or  the  bottom  of  the  message  for 
a  general  comment  on  the  entire  message.  We  could  also  have  specific  comments 
associated  with  each  field  of  the  message,  so  that  a  reviewer  could  key  his  remarks 
specifically,  say,  to  paragraph  three  of  the  message  or  to  the  distribution  list  or  something 
like  that.  Would  either  the  field-by- field  comment  or  the  overall  comment  be  useful  or  not 
useful? 


Yes,  we  talked  about  visually  suppressing  certain  pieces  of  information  where  you 
can  see  them  when  you  ask  for  them.  Those  comments  might  be  handled  in  this  way  so 
that  normally  when  you  look  at  the  draft  of  a  message  you  wouldn't  see  them  and  you 
might  push  a  button  that  says  show  me  all  those  comments  and  the  draft  is  then  split  apart 
and  the  comments  inserted  for  your  viewing. 


9.2.2  Analysis  of  Responses  to  Commenting  the  Draft  Message 

Figure  9-2  shows  the  responses.  The  overall  comment  was  rated  useful,  yet  the 
most  frequent  response  was  necessary  (mode  «  3). 


9.2.3  Remarks  on  Commenting  the  Draft  Message 


Respondent:  Frequently,  if  you  watch  these  people  at  work,  they'll  be  reading 
a  message  and  paging  through  the  refs  at  the  same  time.  You'd  have  to  have 
some  kind  of  split-screen  operation  to  make  it  satisfactory. 

Interviewer:  We  envisioned  split-screen  for  viewing  the  original  draft  and  an 
edited,  returned  copy.  You  could  always  hardcopy  the  references  or  you 
could  use  split-screen. 

Respondent:  You  might  want  to  consider  that. 


Respondent:  Minus  one.  If  you  make  it  too  easy  for  the  "chopper"  to  make 
comments,  he  will.  My  feeling  is  that  if  he  feels  strongly  about  the  message, 
then  he  should  edit  it.  He  has  editorial  license. 


9.3  FIELD-SPECIFIC  COMMENTS  ON  THE  MESSAGE  DRAFT 


9.3.1  Analysis  of  Responses  to  Field-Specific  Comments 

Field-specific  comments  were  deemed  useful,  mean  -  1.5,  see  Fig.  9-3. 


9.4  OVERALL  COMMENTS  ON  THE  RECEIVED  MESSAGE 


9.4.1  A  Question  on  Commenting  the  Received  Message 


These  same  sorts  of  comments  could  be  applied  to  a  message  you  receive  as  wetL 
You  could  have  a  comments  area  at  the  top  or  bottom  of  the  message  and  again 
field-specific  comments.  Let's  say  it's  going  on  a  readboard  where  people  can  send  notes 
to  each  other,  or  you  may  want  to  make  a  personal  note  to  yourself  as  a  reminder  of  the 
status  of  action  of  that  message.  Would  either  one  of  those  be  useful  or  not  useful  for 
released  messages  that  you've  received? 

Would  you  put  that  at  the  top  or  the  bottom  of  the  message? 


9.4.2  Analysis  of  Responses  to  Commenting  the  Received  Message 

Figure  9-4  shows  the  replies  which  indicate  that  an  overall  comments  area  on  the 
received  message  would  be  useful. 


9.4.3  Remarks  on  Commenting  the  Received  Message 


Respondent:  I  think  that  would  be  good  because  I  get  the  readboards  back 
every  day  and  they  are  always  written  all  over.  If  it  is  the  General’s 
comment,  you’d  better  see  it  first. 


Respondent:  I  doubt  if  there  is  an  action  officer  in  this  Headquarters  who 
doesn’t  make  notes  to  himself  as  to  what  he  wants  to  do  with  it,  or  for 
posterity  for  the  next  guy  coming  across. 


9.5  FIELD-SPECIFIC  COMMENTS  ON  THE  RECEIVED  MESSAGE 


9.5.1  Analysis  of  Responses  to  Field-Specific  Comments 

Field-specific  comments  on  the  received  message  rated  only  acceptable,  with  a  mean 
-  0.9,  std.  dev.  -  1.6,  and  mode  -  1. 


9.5.2  Remarks  on  Field-Specific  Comments 


Respondent:  In  fact  that  happened  on  three  messages  yesterday.  On  the  first 
one  they  commented  on  who  sent  it  because  it  was  from  an  organization  we’d 
never  received  a  message  from.  The  next  one  had  a  big  circle  around  part  of 
the  text  and  a  note  saying  ... 


Respondent:  The  General  will  underline  a  word  or  phrase.  You  thould  have 
an  undertcoring  capability. 


9.6  NOTES  ON  A  FILE 


9.6.1  A  Question  on  File  Folder  Comments 

When  we  were  talking  about  the  file  header  information,  we  indicated  that  just  after 
the  file  name  there  was  an  area  for  notes  where  you  could  type  notes  similar  to  writing  on 
the  back  of  a  manila  folder:  comments  or  notes  about  the  entire  file  of  messages.  Would 
that  be  useful  or  not  useful? 

9.6.2  Analysis  of  Responses  to  File  Folder  Comments 

File  comments  were  considered  useful  with  a  mean  »  1.2,  std.  dev.  -  1.4,  and 
mode  »  1. 


9.7  REMARKS  ASSOCIATED  WITH  FILE  EXCERPTS 


9.7.1  A  Question  on  Commenting  File  Excerpts 

And  lastly,  if  you're  looking  at  the  header  information  on  some  file,  you  might  want 
to  add  some  number  of  lines  of  comments  after  one  of  these  entries.  This  is  not  a 
comment  associated  with  the  message  but  just  associated  with  the  header.  For  example, 
you  might  insert  the  status  of  action  of  a  particular  message.  Then,  anytime  you 
displayed  those  headers  you  would  get  the  arbitrary  number  of  lines  of  comments  you  had 
added.  How  would  you  rate  this  feature? 

9.7.2  Analysis  of  Responses  to  Commenting  File  Excerpts 

Comments  on  file  excerpts  was  rated  useful,  with  14  of  18  respondents  rating  it 
highly  desirable  to  necessary;  see  Fig.  9-5. 


9.7.3  Remarks  on  Commenting  File  Excerpts 


Respondent:  That  would  be  good,  especially  on  daily  digest  type  items. 
Someone  could  scan  these  and  it  says  immediate  action  and  then  it  has  a  note 
with  a  date-time  group  saying  action  completed. 
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Interviewer:  What  does  a  daily  digest  item  look  like? 

Respondent:  A  daily  digest  item  has  a  date-time  group,  a  subject,  on  the  top 
of  the  sheet  it  indicates  which  section  it  is  intended  for,  like  J— ,  and  then  a 
suspense  date. 


Respondent:  That  would  not  be  necessary  but  certainly  highly  desirable;  plus 
two. 


Respondent:  Yes,  that’s  a  requirement,  plus  three. 


Respondent:  I  wouldn’t  necessarily  want  them  i'SDlayed  each  time. 


9.8  TAGGING  COMMENTS  WITH  AUTHOR  AND  DATE 


9.8.1  A  Question  on  Automatically  Supplying  Author  and  Date 


One  thing  that  can  be  provided  with  any  of  these  forms  of  comments  (since  we  know 
who  you  are  when  you're  logged  on)  is  that  anytime  you  enter  a  comment  in  any  of  these 
areas  we've  talked  about,  we  can  automatically  tag  it  with  the  author  of  the  comment,  and 
perhaps  the  date.  That  might  be  of  greater  value  on  group  files  like  readboards,  rather 
than  your  personal  files.  How  would  you  rate  that? 


The  service  would  add  your  office  code  and  the  current  date  to  any  comment  you 
enter,  so  you  wouldn't  have  to  type  it.  The  purpose  is  that  (let’s  use  a  readboard  where  a 
couple  of  people  are  making  comments  back  and  forth  on  a  given  message)  it  might  be 
important  to  know  who  made  the  comment.  If  a  general  made  it,  it  might  be  more 
important  than  if  it  were  a  yeoman. 


9.8.2  Analysis  of  Responses  to  Supplying  Author  and  Date 

Seventeen  of  18  respondents  wanted  author  and  date  automatically  generated  by  the 
service.  One  respondent  felt  it  was  acceptable. 


9.8.3  Remarks  on  Automatically  Supplying  Author  and  Date 
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Respondent:  There  are  times  when  someone  tells  someone  else  to  take  some 
action  and  they  say  "well,  I  don’t  remember  it."  If  his  dated  code  were  on  it 
there  wouldn’t  be  any  problem. 


Respondent:  Author,  yes;  date,  no,  because  I  work  in  a  real-time  situation,  so 
it’s  today. 


Respondent:  The  classification  of  remark s  may  raise  the  classification  of  the 
message. 


Respondent:  Could  you  have  a  key  to  get  the  date-time  if  you  wanted  it ?  If 
someone  came  up  with  a  comment  last  evening  and  I  didn’t  see  it  until  this 
morning,  but  in  this  morning’s  traffic  his  comment  has  been  overridden  by  the 
message  traffic.  So,  I  just  discard  it  rather  than  getting  on  the  phone  and 
saying  "hey,  I  don’t  understand,  did  you  see  this  last  message?" 


9.9  ACCESS  CONTROL  TO  COMMENTS 


9.9.1  A  Question  on  Access  Control  to  Comments 


Now,  let's  address  the  question  you  had  a  moment  ago  about  access  controls.  What 
kind  of  access  controls  should  we  apply  to  these  different  remarks  fields?  Let’s  say,  for 
example,  if  we  provide  an  access  control  facility  you  can  apply  it  anywhere,  to  the 
comments  on  draft  messages,  to  the  point  paper,  any  of  these  kinds  of  remarks  fields. 
Here  are  the  kinds  of  things  that  we  could  provide.  One  is  what  we’ve  been  saying, 
everyone  who  has  access  to  a  message  draft  or  file  has  access  to  the  remarks  unless  you  say 
otherwise.  The  second  policy  we  could  adopt  is  that  no  one  has  access  unless  you 
explicitly  say  so.  And  the  third  policy  is  that  if  anyone  can  access  the  message  they  can 
access  the  comments. 


9.9.2  Analysis  of  Responses  to  Access  Controls 

Nine  subjects  preferred  that  the  default  be  that  comments  are  restricted.  One  felt 
that  the  default  should  be  open  comments.  Eight  didn’t  care. 


9.9.3  Remarks  on  Access  Controls  to  Comments 


Respondent:  It  would  be  highly  desirable  to  have  a  place  to  put  a  controlled 
comment  just  for  our  office.  They  may  want  to  know  which  operator  routed 
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the  message.  For  example,  down  in  the  internal  distribution  block,  you  would 
want  a  place  where  you  could  put  OPERATOR  1  or  OPERATOR  2,  and  we  only 
want  that  to  be  seen  by  our  office. 

Interviewer:  Would  you  prefer  to  state  which  offices  could  see  it  or  which 
ones  couldn’t? 

Respondent:  Which  ones  could  see  it.  This  would  be  used  for  quality  control 
to  see  who  is  making  what  kind  of  mistakes.  And  if  they  continue  to  make 
them,  why.  But  it  is  really  just  for  our  use. 

Interviewer:  Make  up  an  instruction  to  show  that  the  comments  have  limited 
access. 

Respondent:  COMMENT  RESTRICTED  TO  J~  AND  J~. 


Respondent:  State  a  group  of  office  codes  that  it  is  restricted  to. 


Respondent:  No  one  can  unless  you  say  they  can.  I  would  want  to  do  this  on 
a  message-by-message  basis. 


Respondent:  Yes.  And  such  controls  are  highly  desirable. 

Interviewer:  Should  it  be  such  that  anyone  who  could  access  the  message  can 
see  the  remarks  unless  you  restrict  it,  or  no  one  can  unless  you  explicitly 
indicate  they  can? 

Respondent:  Anyone  can  unless  you  restrict  it. 


Respondent:  If  it  is  something  I  write  on  there,  then  I  make  a  decision  as  to 
who  it  is  for.  It  may  be  strictly  internal.  It  ought  to  default  to  open  unless 
you  say  it  is  restricted 


Respondent:  The  comments  should  be  restricted.  You  need  control  over  your 
comments  so  that  you  can  pass  them  to  whoever  you  want  to,  but  everyone 
can’t  see  them.  I  think  that  is  very  desirable.  I  think  I,  as  the  user,  should 
specify  who  should  see  it. 


Respondent:  Is  there  any  way  that  you  couldMreat  notes  as  a  message  in 
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themselves,  general  notes  or  something  of  that  nature  where  you  would  be 
building  those  and  adding  to  them  throughout  the  period  that  you  may  be 
working  on  a  particular  project? 

Interviewer:  There  are  some  other  forms  of  communication  such  as  the  office 
memo  that  I  haven’t  talked  about  yet.  But  assume  that  you  can  do  that  — 
that  you  can  have  something  that  is  really  detached  from  the  message. 

Respondent:  See,  these  might  not  apply  to  any  of  the  particular  messages, 
except  in  a  general  way.  But  they  would  be  very  important  to  you  if  you 
owned  the  file,  to  give  continuity  and  to  point  out  sources  of  information  that 
you’ve  used  in  making  up  the  message  --  a  private  note  pad. 


9.10  INTERPRETATIONS  AND  RECOMMENDATIONS 

The  point  paper  it  recommended.  Respondents  were  willing  to  have  the  service 
treat  it  as  text  only;  any  structure  would  be  typed  by  the  person  inputting  the  point 
paper.  As  highlighted  by  italics,  subjects  would  like  to  file  it  and  have  it  return  with  the 
comeback  copy. 

An  overall  comment t  field  it  suggested  for  both  the  draft  mettage  and  the  releated 
mettage.  Reaction  was  mixed  as  to  whether  this  comment  should  appear  at  the  top  or 
bottom  of  the  message.  One  argument  put  forth  for  placing  it  at  the  top  was  that  if  the 
General  wrote  it,  you’d  better  see  it  first.  An  argument  for  following  the  message  with 
the  comment  was  that  it  simply  made  more  sense  to  read  the  message  before  reading  the 
comments  about  the  message. 

Field-specific  comments  on  the  released  message  was  not  supported  by  the 
respohdents.  For  draft  messages,  they  were,  slightly.  We  recommend  neither  its 
presence  nor  its  absence.  If  it  is  provided,  we  strongly  recommend  some  form  of  binary 
suppression  control  (see  Chapter  3)  because  it  was  clear  that  most  users  would  want  to 
be  able  to  see  the  message  in  a  form  closely  resembling  the  standard  format. 

We  do  recommend  an  underscoring  capability  for  both  the  draft  and  released 
message.  Underscoring  and  circling  are  apparently  prevalent  forms  of  highlighting 
message  parts. 

We  feel  ambivalent  about  the  file  header  comments.  It  was  barely  rated  useful,  yet 
it  probably  adds  very  little  to  the  implementation  task.  Comment t  on  file  excerptt  t oat 
alto  rated  only  useful.  Yet,  the  imprettion  toe  received  it  that  the  tubjectt  mere  much 
more  enthutiastic  about  the  file  excerpt  comments.  Most  of  them  suggested  utet  for  this 
feature.  Fourteen  of  18  rated  it  highly  desirable  to  necessary.  We'll  go  along  with  the 
majority  and  recommend  file  excerpt  comments  simply  because  of  the  feeling  we  came 
away  with;  that  ill  would  be  most  useful  to  most  of  the  subjects.  If  this  capability  is 
provided,  thought  should  be  given  to  one  respondent’s  request  which  was  that  he  would 
like  a  suppression  control. 

Comments  in  all  forms  should  be  tagged  with  the  author.  Date  would  be  useful  to 
all  except  those  working  in  the  command  center.  Time  is  important  to  a  few. 
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One  subject  pointed  out  that  a  comment  could  raise  the  classification  of  the  message. 
It  is  not  clear  to  what  extent  the  utility  of  electronic  comments  drops  if  no  attention  is 
given  to  this  issue,  for  the  1977  test.  It  is  certainly  an  issue  to  be  addressed  prior  to  an 
operational  system. 

Access  controls  are  needed.  With  evenly  divided  opinions,  it  would  be  nice  to  have  a 
user-settable,  binary-valued  parameter  such  that  users  could  set  the  default  either  way 
they  desired.  The  domain  of  the  control  should  be  compatible  with  that  of  the  comment. 
For  example,  access  should  be  specified  on  a  message  basis  for  comments  on  messages, 
and  on  a  file  basis  for  comments  attached  to  files  or  file  excerpts. 
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10.  A  PERSONAL  ALERT  MECHANISM 

The  military  community  must  be  responsive  to  their  message  traffic.  The  immediacy 
of  attention  given  a  message  is  a  function  of  its  precedence,  subject  matter,  and  other 
variables.  The  computer  can  reduce  information,  analyze  it,  and  respond  in  a  number  of 
ways.  Thus,  in  this  chapter  we  investigate  the  need  for  individualizing  an  alert  mechanism 
whereby  the  user  can  specify  the  combination  of  message  events  and  notification  media 
for  alerting.  Specifically,  three  questions  relative  to  alerting  were  prepared.  What 
events  need  trigger  alerts  and  how  should  the  user  be  informed?  Is  it  desirable  to  extract 
user-determined  information  from  an  incoming  message  so  that  the  alert  might  be  more 
informative?  Since  the  alert  is  presumably  important,  how  should  the  service  handle  the 
situation  in  which  the  user  does  not  positively  acknowledge  the  notice?  These  questions 
comprise  our  problem  for  this  chapter. 


10.1  PROGRAMMED  EVENTS 


10.1.1  A  Question  on  Programming  Alert  Events 


We’d  like  to  talk  now  about  those  conditions  under  which  something  important  comes 
in  and  you  should  be  notified  in  a  hurry.  I  want  to  show  you  the  ways  in  which  you  might 
control  the  kinds  of  events  you’re  alerted  to,  and  the  mode  of  presentation  of  notice 
information. 

We’ve  indicated  that  there  is  a  reserved  area  on  the  top  of  the  screen  that  would  be 
used  to  alert  you  to  certain  conditions.  We  would  envision  that  when  you  first  begin  to  use 
the  service  that  you  would  fill  in  a  chart  something  like  this  (Fig.  10-1),  that  would 
indicate  the  conditions  to  which  you  wanted  to  be  alerted,  and  the  way  that  you  would 
want  to  be  alerted  to  those  conditions.  A  list  of  some  typical  kinds  of  events  appears  in 
the  right  hand  column.  This  list  is  not  exhaustive,  but  it  suggests  some  of  the  things  to 
which  you  might  want  to  be  alerted.  F or  example,  if  you  had  an  incoming  action  message 
there  are  a  number  of  things  that  could  happen  and  you  specify  in  each  of  these  columns 
in  this  row,  the  conditions  under  which  you  would  want  to  hardcopy,  ring  the  terminal  bell, 
or  display  a  notice  in  your  reserved  area.  This  would  be  based  on  message  precedence. 
For  example,  if  you  put  a  Z  in  here,  any  action  flash  message  would  automatically  be 
hardcopied.  Insert  an  R  and  any  routine  or  higher  precedence  message  (in  other  words  all 
incoming  messages)  would  be  hardcopied,  and  if  you  put  an  0  in  here,  any  immediate  or 
higher  precedence  message  would  be  hardcopied.  If  you  put  nothing  in  there,  then  they 
wouldn’t  be  hardcopied.  The  same  thing  applies  to  the  belL  There  is  a  bell  on  the 
terminal  which  will  ring  for  you  in  case  you’re  not  looking  at  the  terminal  right  at  the 
time  traffic  arrives.  Again,  you’d  determine  thi  precedence  for  this  occurrence.  If  you 
have  an  incoming  action  message,  for  example,  and  you  put  a  Z  in  here  any  flash  action 
message  will  ring  your  belL  If  there’s  an  R,  any  routine  action  message  or  higher  will  ring 
the  belL  If  no  code  appears,  then  the  bell  will  n  >t  ring  under  these  conditions.  Here  you 
can  indicate  exactly  what  you  want  to  have  displayed  in  the  reserved  area,  as  well  as  the 
conditions  for  it.  As  an  example,  suppose  you  get  a  draft  message  coming  in  for  your 
chop.  In  this  example,  for  any  immediate  or  higher  precedence  message  that  comes  for 
review,  this  notice  would  be  printed  in  the  " window .”  You  type  here  exactly  what  you  want 
as  a  notice.  As  we’ve  indicated  here,  it  would  say  DRAFT  FOR  REVIEW  FROM,  then  it 
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would,  pick  out  the  drafter  field  and  insert  that,  and  pick  out  the  subject  field  (30 
characters  of  it)  and  insert  that.  When  an  immediate  draft  message  comes  in,  you  get  this 
statement  (up  here)  (Fig.  10-2)  that  you  specified,  DRAFT  FOR  REVIEW  BV,  the  drafter 
J31t ,  VISITING  CONGRESSMAN.  This  chart,  as  I  say,  is  something  that  you  probably 
would  fill  in  only  once,  when  you  first  begin  to  use  the  service. 

There  are  some  alternatives.  One  alternative  is  that  you're  automatically  alerted  to 
every  incoming  message.  Every  event  causes  an  alert.  Another  alternative  is  that  you  are 
never  alerted  to  any  message  coming  in.  It’s  simply  put  into  your  PENDING  file  and  then 
you  examine  the  PENDING  file,  as  desired. 

How  would  you  rate  the  facility  to  select  the  events  to  which  you  are  alerted? 

10.1.2  Analysis  of  Responses  to  Programming  Alert  Events 

Event  selection  was  rated  highly  desirable  (mean  -  2.5),  with  the  most  common 
reply  being  necessary  (mode  m  3),  see  Fig.  10-3. 

10.1.3  Remarks  on  Programming  Alert  Events 

Respondent:  It  is  necessary  to  say  what  we’re  alerted  to. 


Respondent:  I  would  definitely  want  it  programmed  as  to  specific  things,  like 
immediate  messages,  as  an  example. 


Respondent:  I  think  that  is  absolutely  necessary. 


Respondent:  Since  I  work  in  a  real-time  environment,  this  is  an  absolute 
necessity.  We  get  every  immediate  and  flash  message  at  the  same  time  the 
comm  center  gets  it.  The  reason  the  command  center  exists  is  to  act  on 
messages  as  they  come  in.  A  perfect  example  was  the  Mayaguez.  We  got 
the  first  flash  critics,  and  within  minutes  we  had  people  in  action. 


Respondent:  The  alternatives  are  unacceptable.  This  kind  of  facility  where  I 
have  the  capability  to  establish  the  kind  of  criteria  I  want,  is  a  necessary 
requirement  because,  for  example,  if  I  get  a  flash  action  message  I’ve  got  to 
be  alerted  right  now.  I  want  both  an  audio  and  a  visual  notification  if  I  can, 
and  if  I  get  an  immediate  for  action  then  I’d  rather  just  have  a  visual.  If  it 
can  be  done  in  this  system  without  a  whole  lot  of  difficulty,  I  think  we 
should  have  some  kind  of  alert  system  bated  on  the  criteria  primarily  of 
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Fig.  10-1  Alert  Event  Form 
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precedence,  with  a  follow  on  at  to  the  subject  matter.  If  I’m  looking  for  a 
priority,  a  query  that  I  sent  to  Fleet,  they  may  send  it  to  me  priority  and 
maybe  not,  but  my  problem  is  close  time  constraints  of  meeting  a  suspense  to 
the  J3.  That  is  almost  a  flash  to  me.  So,  I  want  to  be  able  to  establish  a 
subject  criterion  for  it,  even  though  it  is  only  coming  in  as  priority,  or  even 
routine.  I  might  be  met  with  a  "suspense  crunch"  which  to  me  means  that 
when  I  get  that  message  I’m  going  to  react  right  now. 


Respondent:  You  are  really  going  to  use  F  and  I?  That  is  different  from  what 
everyone  else  uses  —  Z  for  flash,  0  for  immediate. 

Interviewer:  Yes.  That’s  in  NTP-3  [NTP-3],  In  the  figure  it  was  an  oversight 
on  my  part. 


Respondent:  You  must  have  a  light.  You  can't  have  a  hell  just  behind  the 
briefing  room. 


Respondent:  Assume  you  were  in  the  middle  of  doing  something  else  and  a 
message  came  in  and  went  into  the  PENDING  file,  and  you  were  expecting  the 
message,  also  assume  that  we  are  going  with  the  third  alternative,  (no  alerts; 
notices  are  placed  in  the  PENDING  file).  Let’s  say  you  are  in  the  middle  of 
drafting  something,  perhaps,  or  looking  at  some  other  messages  and  you  want 
to  just  stop  that  and  take  a  quick  look  at  your  PENDING  file  to  see  if  what 
you’re  expecting  has  come  in.  Is  there  an  easy  way  to  do  that  and  then  come 
back  to  what  you’re  doing  so  that  you  don’t  lose  what  you  composed  or  lose 
your  place  if  you  were  going  through  a  rcadboard? 

Interviewer:  We  had  envisioned  something  similar  to  that,  where  you  are,  in 
fact,  looking  at  a  message  and  let’s  say  you  get  a  notice  and  it  is  of  higher 
precedence  than  the  message  you  are  working  on,  and  you  want  to  attend  to 
it  and  then  come  back  to  where  you  were.  We  could  have  buttons  like  NEXT, 
PREVIOUS,  and  so  forth  that  would  allow  you  to  do  those  things.  A  single 
button  could  mean  "put  away  what  I’m  doing,  but  mark  my  place,  and  give  me 
the  new  message  that  I’ve  been  alerted  to."  Then  after  I’ve  finished  the  new 
message,  a  button  that  means  "go  back  to  where  I  was.”  If  you  had  a  series  of 
these  interrupts  it  would  operate  like  a  cafeteria  plate  stack  in  that  the  most 
recent  one  you  left  (the  plate  on  top)  would  be  the  first  thing  you  would 
return  to  (like  taking  off  the  top  plate):  last-in,  first-out.  What  you’re  asking 
for  is  similar  but  you  would  have  to  establish  the  new  context  by  asking  for 
your  PENDING  file  after  pushing  the  button  to  mark  and  save  what  you  have. 

Respondent:  I  would  need  the  ability  to  go  to  something  else  and  come  back. 
...  I’d  say  a  bell  with  a  volume  control  on  it  would  be  good. 

Interviewer:  What  we  envisioned  was  that  you  could  specify  the  frequency 


and  duration  of  that  bell.  And  also  perhaps  an  off  /on  switch  on  the  console 
so  that  if  you  are  in  the  office  and  going  to  look  at  the  screen  once  in  a  while, 
and  you  don’t  want  to  be  bothered  by  the  bell,  you  could  turn  off  its  effect. 
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Respondent:  Sure.  A  recorded  message  might  be  good.  Like  Ansaphone.  It 
could  say  you  have  so  many  messages  on  subject  such  and  such. 

Interviewer:  That’s  interesting  —  the  message  count.  But  if  it  says  you’ve 
got  subject  such  and  such,  that’s  perhaps  getting  beyond  the  state  of  the  art. 


10.2  PROGRAMMED  NOTICES 


10.2.1  A  Question  on  Personal  Alert  Notices 


What  about  tailoring  the  alert  notices  to  exactly  what  you  want  to  see?  As  we've 
shown  in  this  example  (Fig.  10-1),  you  could  give  literal  text  and  also  pick  up  contents  of 
message  fields.  How  would  you  rate  the  utility  of  this  feature? 


10.2.2  Analysis  of  Responses  to  Personal  Alert  Notices 

Overall,  personalized  notices  teas  rated  desirable  (see  Fig.  10-4),  although  the  most 
frequently  occurring  response  was  highly  desirable.  There  was  a  significant  difference 
between  the  responses  of  officers  (desirable,  mean  -  1.2)  and  those  of  enlisted  personnel 
(highly  desirable,  mean  -  2.2). 
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10.2.3  Remarks  on  Personal  Alert  Notices 


Respondent:  Why  have  a  display  if  you’re  getting  a  hardcopy? 


Interviewer:  That’s  an  option,  whether  you  get  a  hardcopy  or  not.  And  the 
reason  for  giving  you  the  alert  rather  than  the  message  itself  is  that  you  may 
be  in  the  middle  of  working  on  something  else  on  your  CRT.  And  you  may 
either  choose  to  respond  to  the  alert  right  now,  or  ignore  it  and  look  at  it  in 
your  PENDING  file  later.  You  determine  your  priorities,  rather  than  having 
the  system  do  it. 

Respondent:  Being  the  staff  we  are,  we  respond  to  any  action  message.  I 
want  the  terminal  bell.  But  I  see  no  reason  to  display  it  if  I’ve  got  hardcopy. 
If,  in  fact,  the  situation  is  that  I  am  busy  doing  something  else,  why  should  I  tie 
up  the  CRT  with  a  display? 

Interviewer:  One  of  the  things  you  might  be  doing  is  looking  at  messages; 
that’s  what  the  CRT  is  there  for. 

Respondent:  Yes,  but  now  I’ve  tied  it  up  for  10,  15,  Or  20  minutes  looking  at  a 
message  and  something  else  might  be  backlogged  for  display. 

Interviewer:  That  is  why  we’re  giving  you  the  alert  "window"  at  the  top:  to 
tell  you  what’s  coming  in,  and  to  allow  you  to  tell  us  what  fields  you  want 
picked  up  from  the  message  and  shown  there  in  the  top  line,  so  that  you  can 
intelligently  decide  if  the  new  message  is  of  higher  interest.  And  if  it  is,  you 
can  go  work  on  the  higher  priority  item. 

Respondent:  Okay. 


Respondent:  That  would  be  good.  We  have  many  different  messages  coming 
in  from  the  components,  from  XS,  or  whatever.  You’d  be  able  to  determine 
what  that  is.  It’s  going  to  save  a  lot  of  time. 


10.3  UNATTENDED  ALERTS 


10.3.1  A  Question  on  Handling  Unattended  Alerts 


What  about  unattended  alerts?  Let’s  say  that  in  response  to  an  incoming  message  the 
service  displays  a  notice  or  rings  the  bell,  or  whatever  you  have  specified.  Let’s  say  that 
you  don’t  respond  by  saying  show  it  to  me,  or  hardcopy,  and  you  are  not  busy  doing 
something  else  with  the  terminaL  As  far  as  we  can  determine,  you  are  away  from  the 
terminaL  One  thing  we  could  do  it  to  repeat  the  alert  periodically.  Another  thing  we 
could  do  it  route  it  to  another  office  code  or  another  terminal,  or  we  could  hardcopy.  In 
any  event,  it  would  be  put  in  your  PENDING  file.  What  would  you  advise  for  your 
situation? 


10.3.2  Remarks  on  Handling  Unattended  Alerts 


Respondent:  It  would  be  better  for  me  if  you  just  flashed  the  notice  until  I 
acknowledged  it. 


Respondent:  If  you  go  down  the  hall,  you  might  have  several  of  them 
backlogged  when  you  get  back.  It  would  be  nice  to  be  able  to  specify  certain 
messages  to  come  up  first  in  your  PENDING  file.  In  other  words,  anything  that 
was  immediate  or  higher. 

Interviewer:  Would  it  be  sufficient  to  put  all  newly  accumulated  messages  at 
the  top  of  the  PENDING  file  and  flag  them  to  indicate  that  they  had  arrived 
since  you  last  looked  at  the  PENDING  file? 

Respondent:  Right.  Something  to  say  that  these  have  been  added  since  the 
last  time  you  examined  it. 


Respondent:  You  could  give  subjects  and  corresponding  office  codes  so  if  a 
message  comes  in  on  a  subject,  it  would  be  sent  to  that  office. 

Interviewer:  We  could  do  this  through  the  automatic  filing  by  subject  and 
implied  routing  by  the  file  header  instructions. 


Respondent:  We’re  in  there  24  hours  a  day  just  to  monitor  this  kind  of  thing. 
The  only  reason  that  I  wouldn’t  respond  to  that  alert  is  if  I  were  talking  to 
someone  about  something  important,  which  means,  that  I’m  still  interested  in 
this  and  I  want  to  see  it  but  I  don’t  have  time  now  and  I’ll  get  to  it  in  a  few 
minutes.  So,  for  me,  I’d  rather  keep  the  alert  there. 

Interviewer:  If  you  have  many  such  alerts,  we  could  then  repeat  them,  cycle 
through  them  until  you  respond. 

Respondent:  Yes.  That  would  be  fine.  A  staff  agency  might  want  to  do  that 
differently. 


Respondent:  For  example,  say  we  have  an  action  message  for  J4  and  it  comes 
in  after  normal  business  hours.  That  same  message  has  to  come  in  to  the 
command  center  where  an  appropriate  individual  would  review  it  and  take  it 
off  the  machine  as  a  result  of  some  other  type  of  action  he’s  done;  either 
called  the  J4  duty  action  or  deferred  action  until  the  following  morning. 


Interviewer:  It  should  be  rerouted  to  another  destination? 
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Respondent:  Maybe  not  rerouted,  but  multiply  routed. 

Interviewer:  Really  multiply  routed?  If  it  occurs  during  the  day  and  he  is  there, 
then  you  don’t  ordinarily  want  to  be  bothered  with  his  traffic,  do  you? 

Respondent:  Right. 

Interviewer:  So,  you  only  want  his  traffic  routed  to  you  when  he  goes  home 
for  the  day? 

Respondent:  No.  Even  though  a  message  might  come  in  for  an  action  agency 
in  the  Headquarters,  the  command  center  is  still  concerned  with  it  as  a  matter 
of  information,  so  they  would  still  want  to  see  it  on  that  basis. 

Interviewer:  Let’s  see  if  I’ve  got  it  now.  You  both  get  a  copy.  But  now  he 
has  gone  home  and  it  is  for  his  action  and  so  we  need  to  now  give  you  some 
kind  of  an  alert  telling  you  to  take  action. 

Respondent:  Maybe  that  could  be  automatic:  when  he  leaves  he  could  push  a 
switch  on  his  terminal  that  would  kick  in  the  command  center  to  get  visual 
and  auditory  alerts. 

Interviewer:  Okay,  we’re  rerouting  the  alert-,  you  already  get  a  copy  of  the 
message.  Should  that  be  directed  to  you  on  the  basis  of  your  terminal 
identification  or  your  office  code,  or  what? 

Respondent:  You’d  be  directing  it  to  a  terminal.  We  can’t  move  around. 

Interviewer:  Is  the  same  office  code  associated  with  that  terminal,  all  of  the 
time? 

Respondent:  All  of  the  time.  Yes. 

Interviewer:  So  in  you r  case  they  are  one  and  the  same. 

Respondent:  The  last  digit  of  the  office  code  would  change  depending  on 
which  team  was  on. 


Respondent:  Cycle  it  into  the  PENDING  file. 


Respondent:  Periodic  redisplay.  If  necessary,  I  would  specify  rerouting  to 
someone  else  in  my  office. 


Respondent:  Anything  that  comes  in  that  is  immediate  or  flash,  you’d  better 
get  it  to  somebody.  It  also  depends  on  the  message,  what  it  is. 
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Interviewer:  What  kind  of  mechanism  is  needed?  One  facility  could  be  that  you 
could  specify  rerouting  instructions  such  that  if  you  don’t  respond  within  a 
certain  time  period,  depending  on  its  precedence,  it  would  go  somewhere  else. 
And  you’re  saying  it  depends  on  the  subject  matter  as  well. 

Respondent:  Without  getting  needlessly  complex,  that  would  suffice  for  me  — 
subject  matter  and  precedence.  I  have  a  duty  officer  and  he  will  ordinarily 
be  there,  so  it  could  ordinarily  be  rerouted  to  him,  or  if  he  isn’t  there  then  it 
could  be  rerouted  to  the  Duty  Director  for  Office,  the  DDO.  I  think  you'd 
have  to  have  more  than  one  —  perhaps  string  these  together  so  that  if  he 
isn’t  there  it  goes  to  whoever  he  specified. 

Interviewer:  It  isn’t  much  more  difficult,  with  the  code  that  is  needed  for  other 
functions,  to  do  it  very  generally.  Once  we  allow  you  to  specify  one  of  these 
fields  such  as  precedence  or  subject,  we  could  allow  you  to  specify  any  of 
the  parts  of  the  message  that  we  can  scan  --  we  mentioned  that  same 
mechanism  for  retrieving  messages.  We  could  use  that  same  programming  in 
this  context.  The  same  is  true  for  routing  —  the  routing  we  use  for  a 
distribution  list  or  for  getting  a  message  chopped  could  be  used.  So,  it  isn’t 
much  more  difficult  to  provide  the  elaborate  mechanism,  once  we  provide 
anything  at  all. 

Respondent:  People  may  work  differently  in  different  parts  of  the  staff.  So,  I 
think  it  should  be  the  way  you  want  it. 


Respondent:  A  light  on  top  of  the  console  that  stays  lit.  With  the  offices 
here,  if  you  get  a  ding-ding  every  30  seconds,  that’s  not  good. 


Respondent:  I’d  like  to  see  the  alert  repeated  until  it  was  acknowledged.  And 
I’d  like  to  see  a  capability  to  route  it  to  another  office  which  you  could  type 
in  when  you  knew  you  were  going  to  be  out  of  your  office  for  an  extended 
period,  to  cover  your  absence.  It  would  go  to  someone  else  that  you  had  told 
that  you  would  be  gone.  The  light  sounds  good,  then  the  bell  couldn’t  keep 
ringing. 


10.4  INTERPRETATIONS  AND  RECOMMENDATIONS 

We  recommend  the  programmable  event  feature.  No  one  objected  to  the  matrix 
form  for  specifying  event  types.  Evidently,  it  would  be  useful  to  trigger  notices  not  only 
on  precedence,  but  on  other  message  parts  as  well.  This  is  not  essential,  yet  there  should 
be  commonality  of  the  code  used  for  filing  and  retrieval  operations.  Several  respondents 
suggested  a  light  as  an  auxiliary  alert  medium.  We  support  their  suggestion. 

Although  the  programmed  notice  was  desirable,  and  we  feel  that  is  would  be  very 
useful,  it  is  not  essential. 
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The  preponderance  of  subjects  wanted  to  handle  unattended  alerts  simply  by 
repeating  the  alert  until  acknowledged.  Vet,  some  indicated  the  need  for  alternate  routing; 
their  remarks  were  given  earlier  in  this  chapter. 
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11.  THE  DRAFT  MESSAGE  REVIEW  PROCESS 

This  chapter  concerns  some  of  the  facilities  associated  with  message  preparation. 
Thus,  the  questions  were  asked  primarily  of  those  who  are  involved  in  the  message 
drafting  process.  It  should  be  used  in  conjunction  with  the  Washington  report  [Heafner 
76].  We  highly  recommend  reading  that  report  in  regard  to  draft  preparation.  There  is 
one  notable  difference  in  opinions  of  the  subjects  of  this  study  and  the  Washington  study, 
namely,  with  respect  to  distinguishing  fields  of  various  !;inds  of  reviewers. 


11.1  MAINTAINING  A  SINGLE  VERSION 


11.1.1  A  Question  on  Automatically  Deleting  Old  Versions  of  Drafts 

Rate  the  following  feature.  As  a  new  version  of  a  draft  message  is  composed,  it 
automatically  replaces  the  previous  version.  For  example,  if  you  draft  a  message  and  have 
it  reviewed  by  two  people,  then  you  have  three  versions:  your  original  and  the  two  reviewed 
versions,  perhaps  edited.  If  you  then  modify  your  original  based  on  recommendations  by 
the  reviewers,  the  modified  version  replaces  your  original,  and  you  would  still  have  three 
versions  and  not  four.  You,  of  course,  have  the  ability  to  save  any  old  versions  in  your 
personal  files.  Rate  this  feature  of  having  the  service  automatically  delete  your  previous 
version. 

11.1.2  Analysis  of  Responses  to  Deleting  Old  Drafts 

Respondents  rated  this  feature  highly  desirable,  mean  »  2.0.  As  expected,  there 
was  a  significant  difference  in  the  responses  of  action  officer  support  personnel  (highly 
desirable)  and  message  distribution  personnel  (acceptable). 

11.2  DISTINGUISHING  THE  REVIEWERS 

11.2.1  A  Question  on  Distinguishing  Kinds  of  Reviewers  by  Field  Names 

I  would  like  to  talk  about  the  review  process  of  draft  messages.  In  situations  where 
you're  drafting  a  message,  internally  you  get  chops  or  approvals.  Also,  that  message  may 
impact  another  organization  outside  the  originating  organization,  and  there  may  be  times 
when  you  send  that  draft  over  for  courtesy  comments,  since  it  impacts  them.  Is  that  a 
mode  in  which  you  operate?  And  would  you  Uke  to  aistinguish  on  the  draft  message  itself 
those  two  kinds  of  reviewers:  those  people  within  your  organization  who  must  approve,  who 
chop  it,  and  those  outside  who  have  no  control  over  your  sending  the  message,  but  who 
receive  a  courtesy  copy  for  their  comments? 

11.2.2  Analysis  of  Responses  to  Distinguishing  Reviewers 


Only  two  persons  wanted  to  distinguish  among  reviewer  types.  Contrast  this  result 
with  the  Washington  respondents  [Heafner  76].  The  reason  given  for  the  "no  distinction" 


answer  was  that  people  outside  their  immediate  organization  also,  in  general,  approve  or 
chop. 


1 1.2.3  Remarks  on  Distinguishing  Reviewers 


Respondent:  No  need.  People  outside  also  chop  it. 


Respondent:  Who  they  are;  that  will  tell. 

Interviewer:  The  org  codes  tell  you?  You  wouldn’t  need  separate  fields  on  the 
message? 

Respondent:  It’s  not  necessary.  No.  If  it’s  J5,  I  know  who  they  are. 


Respondent:  Sometimes  we  write  a  message  and  they  say  "Hey,  get  PACAF, 
PACFLT  chops."  Even  though  they  don’t  have  any  control  over  what  we’re 
going  to  say,  our  boss  says  "Well,  we  can’t  send  that  unless  we  have 
concurrence." 


Respondent:  I  think  we  ought  to  have  the  capability  of  going  either  for 
comments  or  concurrence  or  for  info. 

Interviewer:  We’re  talking  about  the  drafting  process.  Do  we  need  info? 
Respondent:  Yes.  If  they  want  to  comment  they  can. 


Respondent:  In  some  cases  they  do  have  control  over  the  content  of  the 
manage.  In  many  case t  a  message  will  come  into  the  Headquarters  that 
impacts  two  or  three  areas.  One  may  be  policy  and  one  may  be  operations, 
for  instance.  It  may  be  a  composite  message  on  policy  and  operations.  The 
policy  portion  of  the  message  has  to  be  coordinated  by  J54  or  J5  and  it 
doesn’t  go  out  without  their  coordination.  We  can't  properly  answer  the  mail, 
so  to  speak,  unless  they  coordinate  on  the  content  of  that  particular  portion 
of  the  message. 


Respondent:  I  have  difficulty  visualizing  the  need  for  separating  the  two 
classes. 


11.3  FEEDBACK  TO  THE  DRAFTER 


11.3.1  A  Question  on  Keeping  the  Drafter  Informed  of  Message  Status 

Now  we  have  a  question  of  feedback  to  the  drafter.  In  earlier  investigations,  some 
people  have  indicated  that,  as  a  drafter,  when  they  send  the  draft  out  within  their  own 
organization,  they  don't  want  to  be  bothered  with  it  unless  there  is  a  problem  with  it  and  it 
comes  back  for  redraft.  Others  say  that  they  want  to  know  exactly  where  it  is  and  what's 
happening  to  it.  They  want  the  feedback  at  each  stage  in  terms  either  of  getting  the 
message  back  or  an  alert  on  their  CRT.  Which  camp  do  you  fit  into? 


11.3.2  Analysis  of  Responses  to  Informing  the  Drafter 

Each  respondent  wanted  feedback,  either  as  an  alert  or  as  the  ability  to  query 

status. 


11.3.3  Remarks  on  Informing  the  Drafter 


Respondent:  I  would  like  to  know  whether  or  not  the  person  I  sent  it  to  got 
the  message. 

Interviewer:  One  facility  the  service  could  provide  is  to  tell  you  whether  or 
not  he  has  displayed  the  draft  or  hardcopied  it. 

Respondent:  I  would  want  an  indication  that  he  has  gotten  the  message,  first 
of  all,  and  then  wS.ther  or  not  he  has  any  comments.  If  he  doesn’t  have  any 
comments  I  want  to  know  that  too. 

Interviewer:  Would  it  bother  you,  as  a  reviewer,  if  someone  sent  you  a  draft, 
for  them  to  be  told  that  you  hadn’t  displayed  it  yet,  or  that  you  had? 

Respondent:  No,  it  wouldn’t  bother  me. 


Respondent:  I  don’t  want  to  send  it  out  and  have  it  die  or  get  lost.  I  want 
feedback.  ...  I’m  not  interested  in  the  chop.  What  I  am  interested  in  is  it 
getting  everywhere  I  sent  it.  And  if  there  is  a  dissension,  an  adverse 
comment,  I  want  to  know  about  it.  Because  it’s  my  responsibility  to  "bird 
dog"  a  message.  My  job  was  not  to  submit  it  to  my  boss,  my  job  was  to  get 
the  job  done,  and  that  includes  a  complete  cycle. 

Interviewer:  So,  you’d  like  to  be  alerted  as  it  goes  to  each  person  for  their 
chop  and  when  someone  chops  it? 

Respondent:  Yes.  It’s  my  job  to  get  that  message  through,  and  if  somebody  is 
sitting  on  it  in  their  "in  box,"  I  want  to  know. 
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Respondent:  That  is  necessary.  You  have  to  be  able  to  keep  track  of  your 
papers.  ...  If  there  is  any  change  it  should  come  back.  Maybe  it  could  work 
on  the  precedence  of  the  message.  If  you’re  drafting  a  flash,  you  want  to 
know  where  it  is  and  if  it  is  hung  up  someplace  you  need  to  go  fix  that.  If  no 
one  has  changed  it  but  it  still  hasn’t  gone,  somebody  is  sitting  on  it,  then  you 
need  to  see  that  person. 


Respondent:  A  lot  of  times  the  question  is  asked,  when  you’ve  got  a  message 
out  for  chop,  “Where  is  it  now?"  It’s  not  so  much  that  you  are  interested  in 
what’s  been  done  to  it,  although  sometimes  you  are.  It  goes  from  A  to  B  for 
chop  and  back  to  A,  and  you  bypass  B  because  you  made  his  correction.  You 
go  A  to  C  for  chop,  he  changes  it  around,  it  comes  back.  You  go  A  to  D. 
Sometimes  it  goes  like  that.  Other  times  it  goes  straight  through  in  serial. 

Interviewer:  (It  was  suggested  that  perhaps  the  status  could  be  highlighted  by 
higher  intensity  when  displaying  the  message  draft.) 

Respondent:  Yes,  because  you  can  keep  track  of  it  that  way. 


Respondent:  1  think  it  is  important  to  know  what  the  status  of  it  is,  and 
whether  it  has  gone  out;  if  not,  you  find  yourself  running  in  circles. 


Respondent:  I  would  prefer  to  get  notification.  How  would  you  find  out  where 
it  was,  if  someone  got  it  and  kept  it,  for  instance? 

Interviewer:  (Proposed  chop  list  structure  and  operation  was  explained,  along 
with  notification,  query,  and  highlighting  of  circle  chops.) 

Respondent:  Very  good.  Beautiful.  I  like  that.  Beautiful.  I  like  that  very 
much.  I  don’t  like  the  notification,  all  I  want  to  do  is  query. 


Respondent:  I  want  feedback  at  each  stage  as  an  alert,  or  put  it  in  the 
PENDING  file. 


1 1.4  DRAFT  MESSAGE  CONTROL 


11.4.1  The  Question  of  Who  Controls  the  Draft  Message 

We  have  a  problem  with  the  control  of  draft  messages.  1  understand  that  if  you're 
drafting  a  message  and  you’re  sending  it  up,  your  superior  can  do  lots  of  things  with  the 
message.  One  thing  he  can  do  with  it  is  to  make  what  seems  to  him  a  minor  change,  chop 
it,  send  it  on  up  and  out.  And  he  may  or  may  not  inform  you  that  he’s  done  that.  To 
circumvent  this,  some  drafters  hand-carry  the  draft  around  now  in  a  serial  fashion  so  that 
they  are  aware  of  any  changes  that  are  made.  Because,  in  the  first  case,  the  message  that 
was  released  wasn’t  the  message  you  drafted,  yet  you’re  responsible  for  it.  Does  that 
situation  ever  occur  here? 


The  point  is  that  it’s  easier  to  make  changes  to  the  message  than  it  was  before. 
Let’s  assume  that  the  drafter  says  to  the  service,  any  time  there  is  a  change  made,  I  want 
to  be  notified  in  some  form.  I  want  to  get  it  back  or  something.  The  supervisor  says,  / 
want  to  change  this  and  send  it  out  just  like  Pve  done  in  the  past.  These  are  conflicting 
requests  to  the  service.  What  procedure  should  we  follow,  in  your  opinion? 


1 1.4.2  Remarks  on  Oraft  Message  Control 


Respondent:  I  would  recommend  that  it  be  changed  by  the  drafter  and  then 
sent  back  to  the  releaser.  The  drafter  has  control. 


Respondent:  They’ll  all  tell  you.  They  love  to  tell  you  when  it  is  wrong.  Few 
bosses  will  unilaterally  tell  you  you  did  a  good  job  when  they've  changed  the 
whole  last  paragraph.  They  love  to  tell  you  bad  news.  Good  news  they 
don’t  tell  you. 


Respondent:  I  think  it  should  go  back  to  the  drafter  unless  the  person  who 
changed  it  makes  a  specific  determination  that  he  is  going  to  send  it  up  and 
then  it  ought  to  change  to  him  as  the  drafter.  Once  he  fiddles  with  my  paper, 
he  has  bought  it  as  far  as  I’m  concerned. 


Respondent:  My  recommendation  is  that  when  any  change  is  made  to  a  draft, 
it  can’t  go  anywhere.  It  has  to  come  back.  It’s  the  drafter’s  message.  It 
shouldn’t  be  controlled  by  someone  making  a  chop  and  then  forwarding  it  on. 


Respondent:  Control  with  the  drafter.  My  experience  has  always  been  that  if 
someone  up  the  line  has  changes,  they  have  you  in  there  about  the  changes. 


Respondent:  It's  been  my  experience  that  when  a  message  is  going  to  be 
changed,  the  drafter  is  called  in.  "This  is  the  change  we  want  to  m»ke.  Do 
you  think  that  changes  the  meaning  of  the  message?"  But  I  think  the  guy  who 
originates  the  message  should  be  in  control  of  it. 


Respondent:  I  really  think  that  answer  should  come  from  J3  and  above. 
That’s  an  internal  procedure  that  the  Headquarters  is  going  to  have  to  live 
with.  I  personally  like  to  know  what's  going  on  with  the  message. 


Respondent:  Yes  it  does.  But  it  is  rare  because  you  usually  have  to  retype  it. 
Interviewer:  (Ease  of  change  was  described.) 

Respondent:  This  is  dangerous.  That’s  a  very  profound  question.  You  might 
possibly  be  able  to  rationalize  around  a  situation  where  the  original  drafter 
might  have  to  corelease  along  with  the  actual  releasing  authority,  if  it  were 
done  entirely  through  electronic  means. 

Interviewer:  (Alerting  was  described  as  an  alternate.) 

Respondent:  In  practice,  it  seems  as  though  the  original  drafter  would  have  to 
sit  "glued  to  the  scope,"  anticipating  anything  like  this  happening,  from  the 
very  time  he  submitted  the  draft  for  review  until  it  was  released.  He  couldn’t 
afford  to  get  up  out  of  his  chair  for  fear  of  something  like  that  happening  to 
him,  unless  he  had  some  way  of  seeing  the  final  copy  before  it  went  out. 
That  is  something  he’d  have  to  do  regularly.  ...  I  don’t  think  there  would  be 
any  qualms  on  the  part  of  a  releasing  authority  to  admit  that  perhaps  the 
action  officer  or  the  originator  of  the  message  could  have  a  little  more 
expertise  in  this  particular  subject  area  than  the  releasing  officer.  I  think 
he’d  be  willing  to  admit  that  the  drafter  ought  to  be  able  to  look  at  the  final 
message  before  it  is  released,  even  though  the  releasing  authority  has  a 
prerogative  of  overriding  what  the  drafter  has  said.  It’s  a  procedure  that 
would  have  to  be  agreed  to  and  it  would  have  to  be  built  into  the  system,  I 
think. 

Interviewer:  If  it  is  built  into  the  system,  then  one  of  them  has  final  control 
—  not  both. 

Respondent:  Have  you  heard  of  the  two-man  concept? 

Interviewer:  Yes.  We  could  certainly  do  that  kind  of  thing,  but  we’d  like  to 
avoid  building  as  much  of  that  kind  of  protocol  in  as  possible. 


Respondent:  Of  course,  there  could  be  options.  The  drafter  could  waive  any 
rights  he  has  to  see  the  final  copy  before  it  goes  out,  if  he  felt  that  there 
wouldn't  be  any  problem  like  this.  Or  the  releaser  could  accept  full 
responsibility  for  any  changes  he  makes  and  not  feel  that  he  is  putting  the 
drafter  on  the  spot. 

Interviewer:  In  practice  that  is  not  the  case,  is  it?  Isn’t  the  drafter  responsible 
for  an  incorrect  message  going  out? 

Respondent:  Again,  that  is  a  complicated  situation.  ...  You  might  have  a 
deeper  involvement  and  not  only  want  to  cover  yourself  but  the  Command  as 
well.  I  think  you’d  have  to  have  some  procedure  for  doing  that.  But  like  you 
say,  it  could  be  procedural  and  not  built  into  the  system. 


11.5  DELEGATION  OF  AUTHORITY 


11.5.1  A  Question  on  Delegating  Review  Authority 

What  features  are  needed  for  delegating  review  authority?  For  example,  as  a 
reviewer,  if  you  delegate  authority  to  someone  to  review  a  message  for  you,  after  he  has 
finished  the  review,  does  the  draft  go  directly  back  to  the  drafter,  or  does  it  go  back 
through  you  first?  Or  is  it  sometimes  one  way  and  sometimes  another? 


1 1.5.2  Remarks  on  Delegating  Authority 


Respondent:  Always  bring  it  back  to  me. 


Respondent:  So  rarely  is  responsibility  for  chop  delegated  that  delegation  — 
if  there  —  is  inherent  in  the  job  one  holds.  I  don’t  believe  that  has  a  part  in 
this. 


Respondent:  It  usually  comes  back,  but  not  always. 


Respondent:  He  continues  it  in  its  chop  chain,  wherever  it  is  going. 


11.6  THE  CIRCLE  CHOP 


Closely  connected  with  the  delegation  of  review  authority  is  the  delegation  of  chop 
authority.  Such  a  chop  is  presently  indicated  on  the  draft  message  by  circling  the  office 
code  of  the  person  for  whom  one  is  chopping,  and  then  initialing  the  draft.  This  issue, 
although  not  initially  appearing  on  our  questionnaire,  was  raised  by  several  subjects. 


11.6.1  Remarks  on  the  Circle  Chop 


Respondent:  /111  the  staff  procedure s  that  I  have  seen  have  a  provision  for  (if 
you  know  that  someone  concurs  on  a  message)  circling  him  and  putting  on 
your  own  initials.  We  have  to  have  some  sort  of  mechanism  to  do  that  here, 

where  it  will  be  apparent  later  that  Colonel - did  not  see  the  message  hut 

the  drafter  knew  that  he  concurred  and  circled  him. 

Interviewer:  Do  we  need  to  input  some  master  list  to  start  with,  indicating  the 
structure  for  circle  chops? 

Respondent:  No.  It  just  needs  to  be  able  to  show  next  to  the  code. 

Interviewer:  Then  I  shouldn’t  restrict  it  in  any  way.  I  should  let  the  drafter 
do  that  for  everyone? 

Respondent:  Yes.  The  releaser  has  to  make  the  decision  as  to  whether  it  is 
satisfactory  or  whether  he  wants  some  particular  individual  to  see  it. 

Interviewer:  So,  it  applies  to  everyone  except  the  releaser?  You  certainly 
couldn’t  circle  chop  the  releaser. 

Respondent:  That’s  right,  /llso  in  this  staff,  sometimes  a  message  has  to  be 
released  before  you  can  get  an  out-of-division  chop.  When  you  deal  with  J-, 
they  are  very  strict  about  that. 

Interviewer:  To  indicate  the  circle  chop  we  could  do  something  like 
underscoring.  For  example,  after  someone  has  chopped,  we  might  put  their 
codes  in  dim  intensity  so  that  when  you  looked  at  it  you  could  easily  tell  who 
hadn’t  chopped.  So,  we  might  underscore  to  indicate  a  circle  chop. 

Respondent:  And  then  you’d  need  to  show,  next  to  it,  who  did  that. 

Interviewer:  Okay.  We  could  do  that  in  parenthesis  following  the  underscored 
code. 


Respondent:  What  about  J4  and  J 5,  how  are  you  going  to  indicate  their 
chops?  They  don't  have  terminals. 


Interviewer:  Probably  what  you  could  do  is  to  put  their  codes  on  there  and 


you  could  indicate  their  chops  by  circle  chops,  after  sending  and  getting  back 
a  hardcopy  from  them.  Or  perhaps  you  need  something  slightly  different  to 
indicate  that  they  did  really  chop  but  that  you  are  indicating  that  on  the 
electronic  message. 

Respondent:  I  think  what  it  means  is  that  you  are  going  to  have  to  have  a 
hardcopy  for  everyone  because  you  can’t  have  one  version  of  the  message 
that’s  chopped  by  half  the  people  and  one  chopped  by  the  other  half. 

Interviewer:  You  can  indicate  on  your  electronic  copy  that  those  people  have 
approved  it. 

Respondent:  Oh  sure,  you  can  do  that  now.  You  don’t  need  to  chop  with 
anyone,  you  can  just  fake  all  the  signatures.  How  are  you  going  to  guard 
against  someone  who’s  in  a  hurry? 

Interviewer:  When  you  do  that,  we  can  indicate  that  it  was  entered  by  you, 
different  syntactically,  but  similar  to  the  circle  chop  where  you  as  a  different 
office  code  are  chopping  for  someone,  we’ll  indicate  that  by  underscoring  and 
associating  your  code  with  it  also.  So,  everyone  will  know  that  you  entered 
the  chop  for  that  guy. 

1 1.7  STRUCTURE  AND  OPERATION  OF  THE  CHOP  LIST 

The  following  paragraphs  are  excerpts  of  descriptions  given  to  those  subjects 
interested  in  the  draft  message  review  process. 

Let  me  describe  the  chop  Lst  and  get  your  reactions  to  some  proposed  features.  You 
said  that  you  would  make  no  differentiation  between  those  who  provide  courtesy  comments 
and  those  who  approve.  So,  let's  talk  about  this  (Fig.  ll-l)  top  part  as  a  field  of  the 
message  and  assume  that  it  is  labeled  CHOP  LIST.  I  really  want  to  talk  about  the  way  it 
functions.  If  you  enter  codes  on  a  single  line  the  draft  would  be  " shotgunned ,”  that  is, 
sent  to  these  people  in  parallel  for  their  chops.  Where  codes  are  entered  on  different  lines 
(in  a  column)  that  means  that  the  draft  goes  to  these  people  in  seriaL  Here,  it  goes  to  this 
guy  and  then  this  one  and  finally  to  the  releaser.  Is  that  a  reasonable  way  to  specify  the 
combination  of  parallel  and  serial  routing? 


Yes,  we  assumed  you  might  want  some  overrides.  If,  for  example,  after  you  have 
gotten  some  comments  back,  you  want  to  skip  this  guy  because,  well,  maybe  he  isn't  going 
to  be  in  this  afternoon,  and  you  want  to  go  ahead  and  send  it  up  here  and  back  to  him 
later.  Rather  than  rewriting  the  list,  when  you  press  the  SEND  FOR  CHOP  button,  you  can 
type  in  explicit  codes  before  pressing  EXECUTE,  and  this  has  the  effect  of  reordering  or 
changing  the  routing. 

Another  feature  that  people  have  mentioned  that  they  want  is  the  ability  to  indicate 
a  circle  chop,  where  you  would  underscore  the  office  code  that  you  now  circle,  and  then  the 
service  would  parenthetically  indicate  the  office  code  of  the  person  who  provides  the 
underscore.  This  is  equivalent  to  your  presently  providing  your  initials. 


100 


That's  right.  You  as  the  drafter  want  to  easily  interrogate  the  status  of  chops.  One 
u/ay  this  could  be  indicated  is  as  follows.  When  someone  decides  to  chop,  he  would  push 
the  CHOP  button,  and  then  his  office  code  would  be  displayed  in  dim  intensity  rather  than 
bright.  Now,  this  gives  you,  the  drafter,  a  quick  visual  means  of  determining  who  has  or 
has  not  chopped.  To  query  the  status  you  simply  display  the  draft  and  the  difference  in 
intensities  stands  out  right  away. 


J3II,  J3I3 

HI 

J6 

J3 


J3I 

COOSO:  36 
CHOP:  33 


Fig.  11-1  Possible  Chop  Lists 


11.7.1  Remarks  on  the  Structure  and  Operation  of  the  Chop  List 

Respondent:  Usually,  when  you  run  a  message,  it  doesn’t  get  out  of  the 
division  until  the  division  chief  has  chopped  it.  Then  it  could  go  to  a  number 
of  people  for  their  comment  or  their  information;  these  are  people  at  the 
working  level.  I  want  to  think  about  that  for  a  little  while  because  that  is  a 
capability  we  really  don’t  have  now.  It’s  not  very  easy  to  do.  Really,  the 
piece  of  paper  goes  from  one  guy  to  another  to  another,  serially,  usually. 
And  sometimes  a  lateral  copy.  But  lateral  copies  don’t  always  go  from  the 
same  level  in  the  chop  chain.  It  would  be  nice  to  be  able  to  stick  out  here 
somewhere,  J — ,  okay,  he  wants  copies  to  go  to  whoever. 

Interviewer:  We  assumed  that  anyone  on  this  list  could  further  send  it  to 
anyone  within  their  own  organization  —  build  a  sublist,  if  you  will,  using  the 
same  structure,  indicating  what  they  wanted  to  happen  in  parallel  and  what  in 
serial.  Would  you  use  the  parallel  routing? 

Respondent:  Yes.  Sometimes  when  you  have  a  really  hot  item,  the  parallel 
routing  really  expedites  it.  It  really  does.  So,  I  think  you  should  have  that 
capability. 


Interviewer:  And  we  should  just  be  very  careful  about  the  nomenclature? 

Respondent:  Well,  that’s  just  my  problem.  Someone  else  maybe  doesn’t  have 
that  problem. 

Interviewer:  No.  We’ve  found  that  everyone  has  that  problem,  but  everyone 
has  a  different  set  of  words.  Everyone  understands  chop,  but  with  any  other 
words  we  pick  such  as  review  or  comment,  there  is  no  universal. 

Respondent:  I  think  he  should  get  it  for  comment,  concurrence,  which  is  really 
chop,  or  for  info. 


Respondent:  If  you  do  it  in  serial  is  there  a  tray  that  you  could  control  the 
timing  such  that  if  you  w  ere  to  send  it  first  to  J —  for  a  chop  and  what  he 
said  about  your  message  was  pertinent  to  what  you  wanted,  it  might,  say, 
involve  some  changes  you'd  like  to  make  before  everyone  saw  it,  could  you 
step  it  in  that  fashion ? 

Interviewer:  The  default  condition  we  assumed  was  that  if  anyone  made  edits 
or  comments,  it  would  come  back  to  the  drafter  before  it  went  any  further. 

Now,  there  are  other  kinds  of  overrides  we  envisioned  like  your  example, 
after  you’ve  gotten  it  back,  for  some  reason  you  want  to  temporarily  skip 
over  some  of  the  chop  list  and  go  up  here  and  then  come  back,  that  kind  of 
thing,  then  rather  than  rewriting  the  chop  list,  when  you  press  the  SEND  FOR 
CHOP  button,  you  could  type  in  an  explicit  office  code  or  codes  before 
EXECUTE.  This  would  revamp  the  order  of  review. 

11.8  INTERPRETATIONS  AND  RECOMMENDATIONS 

We  recommend  maintaining  a  single  version  of  the  draft.  This  bookkeeping  should 
be  assumed  by  the  service,  unlike  the  operation  of  most  TENEX  subsystems  where  new 
versions  are  generally  desirable.  Reviewers  need  not  be  distinguished.  The  list  should 
be  labeled  CHOP  LIST.  It  is  essential  to  allow  the  user  to  query  the  status  of  the  draft. 
We  recommend  dimming  the  codes  of  those  who  have  chopped  as  a  concise  representation 
of  that  status  information.  Alerts,  as  feedback,  are  desirable  but  not  necessary.  All 
respondents  except  two  preferred  that  control  of  the  draft  reside  with  the  drafter.  We 
concur.  The  two  alternate  solutions  (automatically  changing  the  dr  after,  and  the 
corelease)  appeared  earlier  in  the  dialogue  of  this  chapter.  No  one  felt  strongly  about 
incorporating  into  the  service  the  delegation  of  review  authority.  We  agree  that  it  isn’t 
necessary.  If  it  is  provided,  then  the  default  routing  should  cause  the  draft  to  go  back 
through  the  delegator,  but  a  bypass  option  should  be  made  available  as  a  parameter.  The 
circle  chop,  as  brought  up  by  the  respondents,  is  essential.  We  proposed  a  mechanism  for 
handling  this  within  the  chapter;  it  was  endorsed  by  the  respondents  and  it  is 
recommended  by  us.  Allied  with  the  circle  chop  is  the  problem  of  chop  by  those  with  no 
terminal  access.  Again,  we  proposed  a  solution  which  we  recommend.  The  structure  and 
operation  of  the  chop  list  was  highlighted  in  this  chapter.  We  refer  the  reader  to  the 
Washington  report  [Heafner  76]  for  further  detail.  We  recommend  this  procedure  and 
operation. 
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12.  RECEPTION  AND  DISTRIBUTION  FUNCTIONS 

In  a  service  automated  from  writer  to  reader,  the  reception  and  dissemination 
facilities  are  as  important  (if  not  more  so)  as  those  of  preparation.  Our  earlier  studies 
concentrated  on  the  preparation  phase  and  associated  facilities,  simply  as  a  convenient 
starting  point.  Vet  some  aspects  investigated  earlier,  such  as  message  formatting, 
message  retrieval,  and  the  alert  functions,  impinge  on  the  reader  as  well  as  the  writer. 
So,  despite  its  title,  this  chapter  covers  only  a  part  of  the  reader  operations  addressed  by 
the  report.  Here,  we  deal  with  misdirected  messages,  reclassification,  and  the  assignment 
of  action.  The  questions  aren’t  numerically  rated  and  therefore  (as  we  have  generally 
done  throughout  the  report  for  nonnumerically  rated  questions)  we  include  a  moderate 
amount  of  dialogue  in  an  attempt  to  faithfully  convey  the  respondents’  attitudes. 


12.1  ACTION/COGNIZANCE  ASSIGNMENT 

12.1.1  A  Question  on  Action  Assignment 

I'd  like  to  ask  some  questions  now  concerning  reception  and  distribution  functions. 
When  you  receive  an  incoming  message,  you  can  further  assign  the  action  or  cognizance  to 
someone  else  within  your  organization.  How  do  you  do  this  now? 


12.1.2  Analysis  of  Responses  to  Action  Assignment 

With  this  question,  we  had  in  mind  the  downward  assignment  within  a  chain  of 
command,  by  an  action  officer  to  a  subordinate.  Apparently,  this  is  not  something  that 
regularly  occurs  in  J3,  with  the  important  exception  of  the  DDO.  Most  of  the  dialogue  then 
represents  that  of  J3  Administration  (the  message  distribution  personnel).  They  answer 
the  question  in  the  context  of  their  duties,  which,  as  pointed  out  in  Chapter  2,  include  the 
responsibility  for  the  initial  action  assignment  and  distribution  of  an  incoming  message.  /I 
need  teas  identified  by  these  gentlemen  to  automate  the  use  of  their  distribution  index, 
which  is  note  a  manual  operation  teith  a  card  catalog.  Let’s  examine  the  problem  from 
their  dialogue.  Pay  particular  attention  to  the  conversation  with  the  third  respondent. 


12.1.3  Remarks  on  Action  Assignment 


Respondent:  We  do  it  by  subject.  J3  is  broken  down  into  directorates.  Each 
one  of  them  handles  certain  topics:  aircraft,  ships,  nuclear  weapons.  Once 
you  see  the  subject  it  is  easy  to  determine  who  gets  the  action. 

Interviewer:  How  do  you  do  the  action  assignment? 

Respondent:  We  stamp  it  ACTION  and  put  it  in  his  box;  he  comes  by  and  picks 
it  up  about  every  two  hours. 

Interviewer:  Would  you  prefer  to  have  instructions  to  do  it?  You  might  send 
an  action  copy  to  some  office  code  and  information  copies  to  others.  So  you 
need  to  differentiate  between  them. 


Respondent:  Yes. 


Interviewer:  Would  it  be  sufficient  to  have  buttons  labeled  ACTION,  COG,  and 
INFO?  Then  if  you  were  going  to  send  it  to  some  particular  office  code,  you 
would  push  the  appropriate  button  and  type  in  the  office  code.  Then  the 
distribution  list  would  be  updated  to  reflect  this  and  the  message  would  be 
routed  to  that  office. 

Respondent:  Yes. 


Respondent:  We  go  by  subject  of  the  message.  We  have  a  card  file  by 
subject  which  shows  who  is  action  and  who  is  info.  If  it  is  a  subject  we 
handle  every  day  and  we  are  familiar  with  it,  then  we  automatically  Know 
where  to  assign  it.  But  if  it  is  not  familiar,  then  we  look  on  the  card  file.  Or 
if  it  has  a  reference  then  we’ll  look  up  who  had  action  on  the  previous 
message  and  send  it  to  the  same  one.  If  they  sold  action  on  the  old  one,  then 
the  copy  in  our  file  will  show  that  the  action  was  changed. 

Interviewer:  Would  it  help  you  if  the  system  could  tell  you  who  had  action  on 
the  messages  referenced? 

Respondent:  Yes  it  would,  definitely. 

Interviewer:  How  do  you  make  the  person  aware  that  you  have  assigned 
action  to  him? 

Respondent:  We  have  an  action/cog  stamp  that  we  stamp  the  top  copy  of 
their  message. 

Interviewer:  What  kind  of  instruction  would  you  prefer  to  assign  the  action 
using  this  service?  One  thing  we  could  do  is  to  mimic  your  stamp.  That  is, 
you  could  have  buttons  labeled  ACTION,  COG,  and  INFO.  Instead  of  stamping 
the  message  you  would  push  the  appropriate  button  and  type  in  the 
destination  office  code  and  it  would  go  to  them. 

Respondent:  Yes,  or  we  could  say  send  it  to  so-and-so  and  then  say  action. 


Respondent:  We  have  a  card  deck  with  900  or  1000  different  subjects,  along 
with  each  office  that  handle s  that  kind  of  subject.  /]  message  comes  in.  We 
assign  some  office  as  primary  action  on  it,  with  a  notation  that  action  or  cog 
is  given  to  this  office.  We  then  furnish  info  copies  to  the  rest  of  the 
divisions. 

Interviewer:  Would  it  be  useful  to  put  your  card  deck  on-line? 

Respondent:  That's  what  I  was  thinking  of.  The  computer  could  show  you 
the  distribution  automatically  and  if  you  okay  it  then  you  press  a  button  and 
it  goes. 


Interviewer:  One  way  that  could  be  automated  is  as  follows.  Your  card  deck, 
indexed  by  subject,  is  on-line.  The  message  subject  is  compared  with  the 
card  deck  and  when  a  match  is  found  it  then  pulls  out  the  distribution 
associated  with  that  subject.  This  is  presented  for  you  to  edit,  to  instruct  the 
service  to  search  further,  or  to  send  it  out.  Is  this  basically  the  way  you  want 
it  to  work? 

Respondent:  Yes.  That  would  be  fine.  It  should  say  this  is  the  subject  and 
this  is  the  distribution. 

Interviewer:  If  you  had  to  explicitly  ask  the  service  to  perform  this,  what 
instruction  would  you  use? 

Respondent:  Probably,  RESEARCH  ON-LINE  SUBJECTS. 

Interviewer:  And  then  it  presents  the  subject  and  distribution  list.  Now  you 
want  to  say  yes  or  no.  You  either  have  a  button  or  *ype  in  something 
depending  on  how  often  you  do  this.  What  would  you  want  to  do? 

Respondent:  You  do  it  on  every  action/cog  message,  so  you  probably  want  a 
button.  It  could  say  OK  or  DISTRIBUTION  OK.  You  would  want  a  DISTRIBUTION 
CHANGE  button  that  would  allow  you  to  type  in  the  changes  that  should  be 
made  with  respect  to  that  particular  message. 

Interviewer:  This  new  feature  that  we've  just  described,  can  you  give  me  a 
rating  for  it? 

Respondent:  That  would  be  highly  desirable  hecause  that  would  eliminate 
typing  out  the  distribution  on  every  message  and  looking  up  every  subject. 

Interviewer:  Also,  you  might  have  the  capability  to  directly  edit  the 
distribution  as  displayed,  instead  of  needing  a  button  for  that. 

Respondent:  You  want  two  capabilities:  One  to  edit  the  distribution  for  a 
particular  message,  and  one  to  change  the  file. 

Interviewer:  So  you  need  instructions  for  creating  the  file,  for  updating  it  by 
editing  it,  adding  new  subjects. 

Respondent:  That  would  be  super  handy  for  us. 

Interviewer:  Okay.  It  is  easy  for  me  to  offer  you  this  because  I’m  not  working 
on  any  of  the  three  projects  building  these  services.  We’re  making 
recommendations  to  them  based  upon  what  you  say.  Understand  that  this 
isn’t  a  very  hard  thing  to  implement,  but  there  is  an  important  question  of 
time  and  priorities  of  the  various  features  people  recommend.  But,  if  you 
have  this  feature,  you’re  only  creating  the  file  once  so  it  probably  isn’t 
important  what  that  instruction  looks  like.  However,  you  may  update  it 
periodically.  What  kind  of  instruction  should  we  have  to  say  "Show  it  to  me?" 
How  about  just  using  the  DISPLAY  button  and  naming  the  file  so  that  you  just 
treat  it  sort  of  like  a  message  file? 
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Respondent:  That’s  fine.  It  could  be  done  by  subject  references,  just  a 
subject  file.  The  only  time  we  would  look  at  it  would  be  when  someone  says 
"I  don’t  want  to  see  any  more  messages  on  this  subject."  Then  use  would  call 
up  that  subject,  delete  them,  and  maybe  make  a  private  comment  saying  they 
wanted  to  be  deleted. 

Interviewer:  This  file  wouldn’t  be  simply  a  text  file.  There  is  structure 
because,  for  example,  the  service  is  comparing  the  message  subject  to  the 
subject  entries.  We  have  to  differentiate  one  entry  from  another  and  the 
subject  from  the  distribution  list,  and  within  the  distribution  list. 

Respondent:  /  think  it  would  be  bett  to  give  the  subject  and  then  indent  it  for 
the  distribution  where  the  first  one  is  for  action/cog  and  then  list  who  gets 
information  copies. 


Respondent:  The  DDO  can  change  the  action  agency  or  he  can  open  it  up  to 
other  agencies.  He  does  that  by  using  an  open-up  form. 


Respondent:  For  J4  messages  of  immediate  or  flash  that  arrive  after  hours,  we 
call  them  from  the  command  center.  If  it  is  immediate  or  flash,  right  down 
at  the  bottom  is  says  " notified  at".  We  enter  who  we  call  and  the  time. 

Interviewer:  Is  that  field  printed  on  the  message? 

Respondent:  That  comes  out  on  every  immediate  and  flash  message. 

Interviewer:  Just  on  immediate  and  flash? 

Respondent:  Right. 


Respondent:  I  put  a  stamp  on  it  —  A,  I,  or  Z  for  action,  info  or  cog. 

Interviewer:  Would  you  prefer  to  enter  the  letter  along  side  their  code,  or 
would  you  prefer  an  explicit  instruction? 

Respondent:  I  think  there  ought  to  be  a  tableau  you  could  fill  in.  ...  We  don’t 
want  to  get  hung  up  on  whether  it  was  an  action  or  an  info  message  in  the 
first  place.  Just  because  we  put  an  A  on  the  message  doesn’t  necessarily 
mean  we  own  the  action.  Maybe  we  are  going  to  take  action  on  it  which  is 
related. 

Interviewer:  You’re  saying  that  you  can  receive  an  info  message  that  you’ll 
assign  action  on? 


Respondent:  Yes. 
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12.2  BUYING  ANO  SELLING  ACTION  ON  A  MESSAGE 


12.2.1  Question  on  Informal  Agreements 

I  have  a  question  about  buying  and  selling  action  on  the  message.  You’ve  gotten  a 
message  [or  action  that  doesn’t  belong  to  you.  My  understanding  of  the  procedure  is  that 
by  telephone  you  informally  agree  u/ith  the  buyer  on  the  transfer  of  action  on  the  message. 
Then  someone  on  your  side  fills  out  a  form,  sends  it  back  to  the  comm  center  and  then  the 
message  is  reissued  and  the  action  is  assigned  to  the  other  party.  Now  we  can  do  this 
electronically.  What  we’d  like  to  do  is,  again,  have  you  informally  agree  to  the  buy/sell 
action  rather  than  having  this  as  formal  protocol  in  the  service,  and  then  just  have  you 
issue  an  instruction  to  change  the  action  to  some  other  office  code.  If  that’s  acceptable, 
then  what  we’d  like  to  know  is  how  would  you  instruct  the  service.  What  kind  of  button  or 
name  would  you  like  to  indicate  that  you’re  transferring  the  action  on  this  message? 


12.2.2  Analysis  of  Responses  to  Action  Transfer 

Our  question  to  the  first  few  respondents  was,  "How  do  you  buy  and  sell  the 
action?"  The  question  was  refined  throughout  the  interviews  to  the  form  given  above.  We 
state  this  here,  because  some  of  the  responses  (from  the  early  interviews)  seem  to  restate 
the  above  question,  but  they  were  really  answering  the  earlier  form  of  the  question. 

In  any  event,  the  consensus  was  that  reaching  the  huy/sell  agreement  is  done 
informally  (only  two  wanted  it  to  be  formal)  and  could  remain  so.  The  users  would  like  a 
button  labeled  REASSIGN  ACTION  or  SELL  which  would  have  the  effect  of  completing  a 
transfer  of  action  form  and  resubmitting  to  the  comm  center.  All  respondents  answering 
the  question  wanted  the  service  to  handle  the  transfer  of  action  and  reissue  the  message. 


12.2.3  Remarks  on  Action  Transfer 


Respondent:  We  just  coordinate  with  them:  go  down  and  see  them  or  call  them 
on  the  phone  to  let  them  know  that  it  is  their  message  and  not  J3’s. 

Interviewer:  So  you  do  that  informally? 

Respondent:  Yes. 

Interviewer:  I  understand  that  after  an  agreement  is  reached  a  form  is  then 
completed  to  officially  indicate  the  transfer  of  action. 

Respondent:  Yes,  you  type  "action  change  J3  to  J6.“ 

Interviewer:  So,  one  way  you  could  do  that  is  to  press  a  button  labeled 
ACTION  CHANGE  and  type  the  office  code  of  the  redirection. 

Respondent:  Action  change.  One  week  you  might  not  get  any  and  the  next 
week  you  might  get  ten  of  them.  But  it  is  really  something  you  have  to  have. 
It  might  average  four  or  five  a  day. 


Respondent:  An  action  officer  in  J3  will  call  an  action  officer  in  J5  and  tell 
him  the  date-time  group  and  the  tub  ject,  and  he  will  open  up  a  copy.  If  the 
JS  determinet  that  they  thould  get  it,  the  J3-  will  make  out  a  change  theet 
taying  " action  from  J3  to  J S." 


Respondent:  The  problem  it  that  not  everyone  will  be  on  the  tystem.  And 
mott  of  the  onet  we  deal  with  are  outtide  J3.  What  we  were  hoping  to  do 
wat  to  get  a  copy  on  the  tcreen  of  the  tell  theet,  the  way  it  appeart 
downtlairt.  There  it  one  for  internal  and  one  for  external.  It  would  be  nice 
to  punch  up  all  the  information  on  the  theet  and  then  have  the  computer  tend 
it  back  downttairt. 

Interviewer:  To  LDMX,  you  mean? 

Respondent:  Yes. 

Interviewer:  Okay,  to  we  need  an  inttruction  to  call  up  the  tell  theet.  We 
have  a  button  labeled  draft  which  you  then  type  in  the  name  of  the  form  you 
want,  tuch  at  a  DD-173  or  tome  pro  forma  form.  You  could  use  this  and 
type  in  the  form  number  or  name  of  the  sell  sheet.  Or  you  could  have  an 
entirely  different  instruction  such  as  SELL. 

Respondent:  That  would  be  very  good  to  ute  DRAFT  and  type  the  name. 
That  would  give  ut  accett  to  all  the  formt  we  need  without  uting  up  buttont. 

Interviewer:  MITRE  publithed  copiet  of  the  buy/tell  formt  recently.  If  I 
copy  thote  will  that  be  okay? 

Respondent:  Not  really.  There  have  been  tome  changes.  We  haven’t  even 
updated  the  changet  ourtelvet,  becaute  we’ve  jutt  reorganized  half  of  the 
divition. 


Respondent:  1  just  send  it  back  down  to  the  admin  section  and  tell  them  it  is 
not  for  me  and  who  I  think  it  should  be  for. 

Interviewer:  How  do  you  know  who  it  should  be  for? 

Respondent:  From  experience. 

Interviewer:  Do  you  mark  on  the  message  to  indicate  who  it  should  be  for? 

Respondent:  Yes.  I  just  say  "action  should  be  with"  whoever  I  think  it  should 
be  with.  Right  now  I  usually  call  them  on  the  phone. 

Interviewer:  If  you  had  a  button  on  the  keyboard  whose  intent  was  to  send 
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the  message  back  to  be  rerouted  for  action  to  another  office,  what  would  you 
label  that  button?  After  pushing  the  button,  you  would  type  in  the  office  code 
of  where  you  wanted  it  to  go. 

Respondent:  REASSIGN  ACTION. 


Respondent:  Usually  the  assignment  of  this  is  done  by  a  clerk  who  uses  "buzz 
words,"  some  sort  of  a  key  and  so  on,  and  you  can’t  tie  down  an  entire 
division  to  a  responsible  action  just  because  a  clerk  made  what  he  thought 
was  a  good  judgment  but  it  turned  out  to  be  faulty,  or  the  buying  agency’s 
reluctance  to  do  their  job. 

Interviewer:  But  the  informal  phone  call  you  use  now  is  sufficient?  You 
wouldn’t  need  any  instructions  in  the  service  for  negotiating  that  settlement? 

Respondent:  No.  Then  I  fill  out  a  form  and  resubmit  the  message  into  the 
distribution  system  with  the  adjustment  in  action. 

Interviewer:  If  we  provide  that  form  on-line  ... 

Respondent:  That’s  right.  You  call  up  the  form  and  fill  it  in  and  the  system 
should  resubmit  within  the  system  and  redesignate  the  action  agency,  with  the 
proper  open-up  or  cognizance  of  other  agencies. 

Interviewer:  You’re  going  to  indicate  the  open-ups  as  you’re  reassigning? 
Respondent:  Yes. 


Respondent:  You  could  put  something  in  your  machine  analogous  to  the  piece 
of  paper  that  is  used  now.  There  is  a  form  and  it  is  fine.  It  simply  names 
the  two  parties  to  the  transaction.  And  at  the  same  lime  that  you  do  that  you 
can  also  do  open-ups.  Because  lots  of  times  I’ll  buy  a  message  that  was 
misrouted  and  ask  them  to  also  open  J-,  so  that's  two  things  done  at  the 
same  time. 


Respondent:  That’s  a  very  important  function.  I  was  thinking  of  a  more 
positive  method  of  the  individual  who’s  going  to  buy  the  message  inserting 
his  approval  into  the  system. 

Interviewer:  We  can  do  that.  We’d  like  not  to. 

Respondent:  He  has  to  look  at  the  message.  I  think  that’s  important.  If 
someone  calls  and  says  "I've  got  a  message  about  nuclear  reactors  in  Viet 
Nam",  and  I  say  "We’re  nuclear  reactors  down  here,  but  I’m  not  sure  we’re 
nuclear  reactors  in  Viet  Nam,  we  never  had  anything  to  do  with  nuclear 


reactors  in  Viet  Nam,  maybe  we  are."  But  the  thing  is,  before  I  accept  that. 
Pm  going  to  tee  that  mettage. 

Interviewer:  When  you’re  talking  on  the  phone,  he  can  certainly  open  you  on 
the  message  and  now  you  have  a  copy  to  examine. 

Respondent:  But  then  after  you’ve  teen  it,  the  guy  ought  to  have  the 
capability  of  inputting  hit  acceptance  of  the  action/cog. 

Interviewer:  How  would  he  do  that?  I'm  looking  for  vocabulary.  How  would 
you  say  to  the  system  that  you  want  to  accept  this  message  that  you’re 
looking  at? 

Respondent:  ACCEPT  ACTION. 

Interviewer:  On  the  seller’s  part,  would  he  have  to  say  anything? 

Respondent:  Yes.  CHANGE  ACTION  TO  so-and-so. 


12.3  DELEGATING  ACTION  AUTHORITY  AND  TERMINAL  GUARDING 


12.3.1  Questions  on  Delegating  Action  Authority  and  Terminal  Guarding 

In  delegating  authority  for  someone  to  act  in  your  behalf,  should  the  service  be  told 
by  explicit  instruction,  by  your  entering  a  name  in  an  access  list,  or  by  the  delegatee 
entering  your  temporary  password? 


What  features  should  the  service  provide  for  guarding  when  you  are  away  from  your 
terminal  for  an  extended  time  period,  such  as  days  or  weeks?  Should  the  incoming  traffic 
be  rerouted  to  a  person  or  office  code,  or  to  a  terminal? 


12.3.2  Analysis  of  Responses  to  Delegating  Action  Authority 

Several  questions  such  as  the  above  were  asked.  In  general,  the  respondents  felt 
that  such  features  were  not  needed,  beyond  those  requested  and  discussed  in  Chapter  10 
concerning  unattended  alerts. 


12.3.3  Remarks  on  Delegating  Action  Authority  and  Terminal  Guarding 


Respondent:  That  doesn’t  happen.  I’m  never  gone  more  than  10  or  15 
minutes.  It’s  very  unlikely  that  anyone  would  be  gone  for  more  than  an  hour. 
Just  repeat  the  notice  every  5  or  10  minutes. 
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Respondent:  It's  not  needed  because  there  will  always  be  someone  around  to 
get  it.  After  say,  1600  in  the  afternoon  until  midnight  there  won’t  be  anyone 
on  our  terminal.  The  DDO  or  somebody  in  that  area  will  get  it. 


Respondent:  It’s  not  needed.  In  J3  we  have  three  people:  one  for  night,  one 
for  morning,  and  one  for  afternoon.  They  are  all  doing  basically  the  same 
thing.  So  we  would  all  be  identified  by  the  same  office  code. 


Respondent:  It’s  always  addressed  as  org  code.  Very  seldom  do  we  get  a 
message  addressed  to  a  person.  There  will  always  be  someone  in  the  office 
who  can  act  for  the  office  code. 


Respondent:  No.  There  would  always  be  someone  there.  Someone  would 
always  take  the  place  of  that  office  code. 


Respondent:  No.  Our  desk  is  manned  24  hours  a  day.  I’m  one  of  five  officers 
who  man  that  desk.  So  someone  will  be  there. 

Interviewer:  So  the  incoming  traffic  is  addressed  to  that  desk? 

Respondent:  That’s  right. 


Respondent:  For  GENSER  staff  it  is  all  by  function,  the  organizational  function, 
regardless  of  who  the  people  are.  If  you’re  going  to  expand  this  later  on  to 
SI  and  compartmented,  where  there  are  only  certain  individuals  and  they  are 
usually  named  in  the  message,  who  can  see  it  by  name  ... 


Respondent:  Traffic  comes  in  by  office  code,  so  this  is  not  a  problem. 


Respondent:  Right  now  we  have  a  system  where  the  other  section  chief  over 
there  where  I  am  now  does  it. 


Interviewer:  How  is  he  identified  differently  from  you? 

Respondent:  I  would  do  it  by  code.  How  do  I  do  it?  The  day  I  leave  do  I  type 
in  "send  all  my  files  to  J— ?"  All  incoming  traffic. 
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Interviewer:  I  want  to  know  exactly  what  is  necessary.  What  is  a  good 
instruction  name  for  that? 

Respondent:  Basically,  what  I  would  want  to  say  is  "route  all  incoming 
messages  to  J — 

Interviewer:  So,  the  keyword  here  is  "route"  and  then  you  would  type  in  his 
office  code? 

Respondent:  Yes. 

Interviewer:  And  that  would  remain  in  effect  until  you  came  back  and  said 
route  to  your  office  code? 

Respondent:  Yes,  or  delete  that  instruction,  or  whatever. 


12.4  MESSAGE  RECLASSIFICATION 


12.4.1  A  Question  on  Message  Reclassification 

A  different  kind  of  question:  downgrading  and  declassification.  Let’s  assume  in  the 
declassification  field  you  enter  CDS  or  ADS.  At  some  point  in  time  we  know  that  we  have 
to  change  the  classification  on  the  message  so  we  pull  up  the  master  copy  from  archive 
and  make  the  appropriate  changes  in  the  classification.  One  thing  we  could  do  following 
that  is  to  look  at  the  distribution  list,  send  a  notice  to  all  those  people  on  the  distribution 
list  saying  this  message  has  been  reclassified,  or  we  could  only  change  the  classification  on 
the  master  copy.  We  certainly  can’t  affect  hardcopy  files  people  may  have.  Is  it 
necessary  for  us  to  send  a  notice  to  the  distribution  list  telling  them  that  the  message  has 
been  reclassified? 


12.4.2  Analysis  of  Responses  to  Message  Reclassification 

In  response  specifically  to  the  above  question,  exactly  half  of  the  subjects  stated 
that  notification  should  be  sent.  One  respondent  suggested  a  compromise  solution 
whereby  users  would  be  periodically  notified  of  downgraded  messages  of  which  they  had 
received  a  copy. 

Independent  of  declassification,  it  was  brought  to  our  attention  that  we  were 
overlooking  a  very  necessary  requirement  in  terms  of  reclassification.  In  this  instance,  a 
message  is  issued  with  an  incorrect  classification.  Later,  a  second  message  is  issued 
stating  the  correction.  The  service  should  provide  for  correcting  the  classification  of  the 
original  message. 


12.4.3  Remarks  on  Message  Reclassification 


Respondent:  We’re  instructed  to  put  that  on.  When  it’s  downgraded,  you 
should  send  a  notice  to  the  people  who  received  it. 
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Respondent:  What  you  would  really  have  to  do  is  to  send  out  another  action 
message  to  all  recipients. 

Interviewer:  And  we  would  also  have  to  change  the  classification  fields  of  the 
archived  copy  of  the  message. 

Respondent:  That’s  right. 

Interviewer:  Now,  none  of  this  will  probably  happen  in  this  test  next  year,  but 
I  ask  the  question  because  we’re  also  interested  in  features  of  a  later 
operational  system. 

Respondent:  The  only  thing  that  would  happen  within  a  year,  probably,  would 
be  change  in  classification,  say,  from  Confidential  to  Secret. 

Interviewer:  Is  that  something  that  you  would  explicitly  do? 

Respondent:  That’s  right. 

Interviewer:  Who  has  authority  to  do  that? 

Respondent:  First  of  all,  there  are  instructions  as  to  what  the  original 
classification  should  be.  The  originator  does  that.  So,  the  originator  or 
originating  office  has  to  change  it. 

Interviewer:  According  to  NTP-3,  each  paragraph  has  a  classification.  He  can 
change  or  upgrade  the  classification  of  a  single  paragraph  as  well  as  the 
whole  message? 

Respondent:  Yes.  That’s  right. 


Respondent:  But  don’t  tell  everybody  that  ever  received  that  message  that  it 
has  been  downgraded.  Again,  that’s  an  unnecessary  feature. 


Respondent:  I  think  the  system  should  have  a  very  simple  format  for 
readjustment  of  downgrading  and  upgrading  the  reclassification. 

Interviewer:  What  should  we  do  as  a  result  of  your  typing  instructions  into 
that  field? 

Respondent:  There  is  not  much  you  can  do. 

Interviewer:  Well,  a  couple  of  things.  One  is  that  we  can  change  the 
classification  fields  of  the  message  in  the  master  archive. 
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Respondent:  You  must  go  to  the  positions,  to  the  action,  the  info.  It  has  to  be 
changed. 

Interviewer:  People  may  have  made  hardcopies.  I  can’t  change  those.  But  I 
can  inform  them. 

Respondent:  Yes. 

Interviewer:  Then  it  is  sufficient  to  send  a  notice  to  the  distribution  list  saying 
that  it  has  been  downgraded? 

Respondent:  Or  that  you  blew  it,  it  should  have  been  secret  instead  of 
confidential. 


Respondent:  Except  for  ADS,  I  think  that  is  something  better  left  alone. 


Respondent:  By  the  book  you  should  send  notification. 


Respondent:  I  think  you’d  have  to  notify  them.  You  might  also  want  to  remind 
them  that  they  have  a  hardcopy. 

Interviewer:  Well,  we  could  know  who  made  hardcopies  through  the  system, 
but  we  certainly  wouldn’t  want  to.  Also,  someone  could  copy  a  printed  copy 
using  facilities  outside  the  service.  We  have  no  control  over  that. 

Respondent:  Yes.  That’s  true.  You  might  periodically  give  him  a  list  of 
me**aget  that  have  been  ioungraded. 


Respondent:  I  would  think  that  we’d  have  to  let  them  know  some  way.  Could 
we  look  at  it  from  two  different  angles?  One  being  a  mistake  when  the 
message  was  sent  out  and  you  want  to  clarify  that.  And  that  I  would  think 
would  apply  not  just  to  classification  mistakes  but  any  mistakes  in  content. 

Interviewer:  You  want  to  cancel  or  recall?  We  haven’t  talked  at  all  about 
cancellation  or  recall. 

Respondent:  It’s  done  pretty  frequently.  Quite  often  when  you  get  a  busy 
period  and  something  goes  out  that  isn’t  complete  or  is  misdirected,  then  you 
have  to  send  a  follow-up  message  correcting  what  has  happened.  For  a 
longer  period,  as  the  time  critically  wears  off,  the  need  for  the  follow-up 
notification  is  less  and  less. 
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12.5  INTERPRETATIONS  AND  RECOMMENDATIONS 

The  administration  functions  associated  with  action  assignment  were  introduced  in 
Chapter  2.  In  this  chapter  these  enlisted  personnel  responsible  for  message  distribution 
relate  their  use  of  the  card  index  file  in  action  assignment.  Together  we  develop 
proposed  automated  aids  to  facilitate  their  job  performance.  Although  it  is  not  absolutely 
essential  to  put  their  card  index  file  on-line,  its  use  is  integral  to  their  primary  function. 
Therefore,  we  recommend  the  on-line  subject/distribution  file  with  the  supportive  features 
developed  in  the  beginning  of  this  chapter. 

Instructions  for  the  action/cognizance  assignment  to  subordinates  is  not  needed.  To 
the  extent  this  is  used  it  can  be  handled  through  annotation. 

We  recommend  that  the  buy/sell  negotiation  be  conducted  informally.  An 
instruction  to  transfer  the  action  is  desirable.  However,  this  requires  supporting  software 
in  LDMX  as  well  as  in  the  test  service  system.  This  may  not  be  feasible;  thus  it  may  not 
be  possible  for  on-line  action  transfers  to  persons  not  using  the  test  service.  Yet,  the 
paper  work  necessary  for  the  comm  center  can  be  done  on-line  in  any  event.  If  this  is 
pursued  by  the  designers,  then  note  that  the  buy /sell  forms  have  recently  been  changed. 

With  respect  to  delegation  of  authority  and  terminal  guarding,  those  features 
proposed  in  Chapter  10  for  rerouting  are  sufficient  for  GENSER  traffic. 

The  ability  to  reclassify  a  message,  under  explicit  instruction  from  the  originator,  is 
needed.  This,  for  the  purpose  of  correcting  mistakes.  Our  understanding  is  that  the 
general  downgrading  problem  will  not  be  addressed  by  the  test  service. 


13.  COMPLEMENTARY  COMMUNICATIONS  METHODS 


In  previous  chapters,  it  has  been  brought  out  by  numerous  respondents  that  a  large 
part  of  their  activities  involve  formal  correspondence  other  than  message  traffic;  in  some 
cases  up  to  707,  of  their  time  is  devoted  to  nonmessage  correspondence.  From  the 
Washington  study  [Heafner  76]  it  was  learned  that  in  times  past  the  use  of  pony  linkt  or 
mire  notes  was  found  to  be  useful  for  a  broad  range  of  informal  correspondence,  but 
was  eliminated  because  of  their  lack  of  formality  and  accountability.  But  what  of  the 
electronic  assistance  for  more  local  and  restricted  informal  correspondence? 

The  nucleus  of  the  communications  services  thus  far  proposed  could  be  readily 
adapted  to  encompass  complementary  forms  such  as  formal  memorandums  and  informal 
notes.  In  addition,  interactive  person-to-person  dialogue  (for  perhaps,  purposes  of 
discussing  a  message)  could  be  supported  by  directly  (logically)  linking  terminals.  Such  is 
the  substance  of  this  chapter. 


13.1  IN-HOUSE  RECORD  COMMUNICATIONS 

13.1.1  A  Question  on  Formal  Intraorganization  Correspondence 


I’d  like  to  ask  a  couple  of  questions  now  about  using  the  service  for  forms  of 
information  other  than  record  messages.  One  of  the  forms  of  communication  that  we  could 
provide  (using  essentially  the  same  sorts  of  facilities  we've  talked  about:  the  file 
organization,  the  alerting  mechanism,  notifications  and  so  forth)  is  an  in-house  formal 
record  communications:  memorandums  or  perhaps  some  standard  forms,  or  whatever  would 
be  applicable.  There  would  be  accountability  in  the  sense  that  correspondence  would  be 
archived.  How  would  you  rate  such  a  facility? 


13.1.2  Analysis  of  Responses  to  In-house  Communications 

This  feature  was  rated  desirable  with  the  most  common  reply  being  highly  desirable, 
see  Fig.  13-1.  The  most  frequently  identified  uses  were  for  intraoffice  memorandums 
and  interagency  memorandums  within  the  CINCPAC  Headquarters. 


13.1.3  Remarks  on  In-house  Communications 


Respondent:  I  think  that  would  be  highly  desirable  within  a  close  organization 
that’s  manned  24  hours  like  the  command  center. 

Interviewer:  What  kinds  of  things  would  you  use  it  for  in  the  command  center? 
Respondent:  Status  of  actions,  informal  notes. 
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Respondent:  It  is  just  as  important  as  the  other  (formal  record  traffic). 


Respondent:  We  would  use  it  for  formatted  point  papers,  WEB  (Weekly 
Executive  Brief),  background  papers  and  progress  reports  which  are  mostly 
free  forms. 


Respondent:  Oh  yes.  I’m  up  to  600  memos  already  this  year. 
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13.2  INFORMAL  MESSAGES 


13.2.1  A  Question  on  Non-Record  Communications 


Now,  there  are  a  couple  of  other  forms  of  communication  that  we  could  provide. 
One  is  a  totally  informal  message  service  with  the  same  sort  of  features  that  we’ve  talked 
about,  except  for  archival.  No  recording,  no  accountability.  This  is  something  akin  to  a 
phone  conversation,  perhaps,  where  you  want  to  discuss  the  content  of  a  message.  It  has 
the  following  features.  It’s  secure  whereas  most  of  your  phones  are  not.  It  allows  you  to 
leave  a  message  in  someone’s  "in  box"  when  they  are  not  in  their  office.  It’s 
" off-the-record "  as  a  phone  conversation  would  be.  How  would  you  rate  the  utility  of  that 
feature? 


13.2.2  Analysis  of  Responses  to  Non-Record  Communications 

Informal  messages  would  be  useful;  see  Fig.  13-2.  Those  respondents  who  asked 
about  the  range  of  recipients  of  informal  messages  felt  that  its  use  should  be  restricted  to 
within  the  Headquarters. 


13.2.3  Remarks  on  Non-Record  Communications 


Respondent:  That  is  almost  a  necessity.  That  would  be  very  handy  for  lots  of 
people. 


Respondent:  The  informal  is  what  we  need  in  the  command  center. 


Respondent:  It  is  highly  desirable.  My  rationale  is  that  you  may  want  to  say 

"What  is  the  status  of - .  It  is  getting  close  to  my  suspense  date,  are  you 

going  to  make  it  tomorrow?"  You’re  thinking  about  intraoffice  messages? 

Interviewer:  Not  with  the  informal.  Earlier  I  thought  so,  but  I’m  told  it  could 
go  anywhere. 

Respondent:  Not  a  message  out  of  the  Headquarters.  You’re  thinking  of  an 
informal  out  of  the  Headquarters?  You  don’t  get  informal  out  of  the 
Headquarters.  Out  of  the  Headquarters  is  a  formal  communication. 


13.3  DIRECT  TERMINAL  LINKING 


13.3.1  A  Question  on  User-User  Network  Communications 

How  about  direct  ter minal-to- terminal  Unking?  Now  you  are  interacting  in  real-time 
and  what  you  type  appears  on  my  screen,  and  vice  versa,  so  that  we  each  have  displayed 
the  dialogue  of  our  " conversation ."  That  is  different  from  leaving  a  note  in  someone’s  "in 
box"  Both  of  them  are  informal  with  no  record  keeping,  unless  you  want  to  get  a  hardcopy. 
The  service  will  not  archive  the  transcript.  Both  are  secure.  How  would  you  rate  the 
direct  Unking  faciUty? 

13.3.2  Analysis  of  Responses  to  Direct  Communications 

Linking  was  rated  useful,  with  the  most  common  reply  being  highly  desirable;  see 
Fig.  13-3.  There  was  a  significant  difference  between  the  administration  personnel 
(acceptable  rating)  and  the  other  subgroups  (highly  desirable  rating).  Several  subjects 
asked  for  an  on-line  conferencing  capability. 


13.3.3  Remarks  on  Direct  Communications 


Respondent:  You  may  have  a  guy  drafting  a  message  and  he  may  want  a  quick 
input  from  someone  and  he  could  ask  directly. 


Respondent:  That  would  be  used  in  crisis  situations.  For  example,  during 
Mayaguez  there  were  communications  going  around  the  room  between  various 
high-ranking  individuals,  including  even  inbound  from  the  Secretary  of  State. 
They  didn’t  want  everyone  else  privy  to  that  information.  They  want  to  be 
able  to  selectively  screen  who  is  going  to  hear  this  information.  Also,  I  could 
see  a  use  for  this  kind  of  communication,  for  example,  where  I  am  working  at 
my  terminal  and  my  boss  is  too,  and  something  comes  in  and  he  wants  to 
interrupt  me  and  say  "Come  over  here"  or  "Do  something."  That  could  be 
used. 


Respondent:  That  would  really  be  great,  because  occasionally  we  can’t  get 
people  on  a  secure  phone.  Every  day  I  talk  with  my  counterpart  at  PACFLT. 
At  4:30  in  the  morning  he  calls  me  on  a  secure  phone  to  make  sure  that  he  is 
briefing  the  Admiral  down  there  exactly  the  same  as  we're  briefing  up  here. 
It’s  just  to  cross  check. 


Respondent:  I  could  save  myself  all  sorts  of  "foot-leather"  because  I  don’t 


have  secure  communications  within  the  Headquarters.  Well,  I  do,  but  it's 
difficult.  I  have  access  but  most  people  do  not,  particularly  action  officers.  If 
we  had  a  secure  display,  that  would  be  a  plus  three.  Notice  I  haven't  rated 
things  very  extremely. 


Respondent:  A  lot  of  people  don’t  have  secure  phones,  or  if  they  do  have 
them,  they  are  not  conveniently  located.  So,  that’s  a  deficiency  that  it  would 
correct. 


Respondent:  It’s  highly  desirable.  I  don’t  know  if  it  is  absolutely  necessary. 


Respondent:  The  idea  of  having  a  secure  facility  I  think  is  good.  ...  I  think 
this  is  going  to  be  great.  I  can  envision  it’s  use  from  an  action  officer’s 
standpoint.  I  can  also  envision  it  from  a  receiver’s  standpoint,  whereby  you 
could  get  a  lot  more  down  from  higher  Headquarters  with  this  readily 
available.  So,  it’s  going  to  work  both  ways.  I  think  it’s  going  to  be  a  good 
thing.  When  the  CINC  wants  something  done,  instead  of  going  through  a 
chain,  it’s  going  to  allow  the  people  in  the  higher-up  positions  to  get  down  to 
the  lower  positions. 


Respondent:  A  conversational  mode  would  be  very  desirable. 

13.4  UNSOLICITED  REMARKS  ON  NONMESSAGE  CORRESPONDENCE  AND  DOCUMENTATION 


Respondent:  Are  we  going  to  be  able  to  record  nonmessage  traffic  in  these 
files? 

Interviewer:  We  give  you  many  ways  to  enter  annotation.  Some  people  have 
indicated  special  forms  that  should  be  included. 

Respondent:  Like  a  memo  for  record.  Would  it  be  possible  to  put  a  memo  for 
record  in  a  subject  file? 

Interviewer:  Sure.  At  the  least  you  could  enter  it  as  annotation  to  the  file, 
according  to  what  we  are  proposing. 

Respondent:  I  think  it  would  be  desirable  to  have  a  memo  for  record  form  that 
could  be  put  into  all  of  these  files  to  record  verbal  conversations. 
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Respondent:  I  want  to  be  able  to  send  it  to  someone  through  someone.  But 
the  "through"  has  the  prerogative  of  stopping  it  right  there  and  readjusting  it 
and  sending  it  bach. 

Interviewer:  We  could  use  essentially  the  same  facilities  as  for  formal  record 
traffic. 

Respondent:  Yes.  The  system  should  be  capable  of  doing  that.  But  it  is  a 
different  format.  It’s  a  structured  format.  And  you  have  other  formats:  point 
papers,  talking  papers,  position  papers,  often  small  three-by-five  cards  that 
are  carried  to  briefings.  ...  A  talking  paper  is  much  the  same  thing,  only  in 
much  more  prose.  A  position  paper  is  a  full  descriptive  format,  it’s  a  position. 
You  may  also  get  into  letters  —  formal  communicative  letters  —  not  messages 
but  letters  that  may  be  addressed  higher  or  lower  in  the  J3  Headquarters. 
But  all  of  these  have  essentially  the  same  format.  We  primarily  do  our  work 
with  messages  and  memorandums.  However,  there  is  a  significant  amount  of 
letters,  explaining  a  position  —  they  may  be  mailed  or  hand-carried.  Now, 
when  the  other  services  input  to  the  joint  arena,  they  are  uniservices  coming 
to  the  joint  arena  and  they  use  their  own  specific  style  of  communicative 
effort  —  primarily  it’s  letters.  But  they  may  also  include,  for  example,  in  the 
Army’s  terms,  disposition  forms  which  is  a  very  specific  Army  informal  method 
of  correspondence.  Now,  the  Navy  has  Fleet  SITR/IMS,  I  don’t  know  what 
the  Air  Force  has. 


Respondent:  There  are  a  number  of  documents  that  we  use,  that  are  JCS 
documents,  DIA  appraisals,  reports,  things  of  this  nature  —  things  other  than 
messages,  which  I  presume  want  to  be  in  the  system.  Sometimes  very  thick 
documents. 

Interviewer:  Only  that  information  that  you  put  in  yourself... 

Respondent:  It’s  nice  to  have  that  kind  of  stuff  available  to  you  via  the 
system.  But  if  I’ve  got  to  type  it  all  out,  no. 

Interviewer:  Once  such  a  system  is  widespread,  then  when  such  a  document  is 
created,  it  can  be  created  on-line. 

Respondent:  It  would  be  great  if  I  had,  for  example,  certain  documents  that  are 
limited  in  distribution,  XS  documents.  A  good  example  is  Joint  Strategic 
Capability  Command  which  I  use  all  the  time  in  my  reviews  of  joint  operations 
procedures  and  things  of  this  nature.  It’s  useful  for  me  to  be  able  to  call  that 
up  in  a  hurry;  otherwise  I’ve  got  to  go  find  the  document.  I’ve  either  got  to 
go  to  the  vaults  or  go  to  another  directorate  and  borrow  his  if  he’ll  let  me 
have  it.  It  would  be  extremely  useful  beyond  the  test,  and  into  the  future,  if 
this  sort  of  thing  can  also  be  placed  into  the  system  supplementing,  if  not  in 
many  cases  replacing,  the  vault-carrying  requirement.  Now  that  can  be  as 
restrictive  as  the  vault  people  want  it  to  be.  They  can  also  assign  the 
restriction  of  being  able  to  call  it  up  to  video  receivers,  but  there  are  certain 
advantages  to  that.  I  wouldn’t  have  to  run  all  over  Headquarters  to  find  that 
document. 


If  I’ve  got  a  document  that  I’ve  sent  out  for  staffing,  but  I  need  it  then  I 
have  to  spend  several  hours  or  take  one  of  my  yeomen  and  have  them  try  to 
find  it.  It  would  be  extremely  useful  to  be  able  to  call  up  a  copy,  go  to  that 
page  number  and  I  have  my  material.  It’s  not  historical,  it  is  current 
information. 

So,  there  are  some  of  the  things  that  could  be  looked  at.  It's  all  part  of 
preparing  messages. 

Interviewer:  In  addition  to  the  filing  and  retrieving,  you  may  want  formatting 
capabilities.  There  are  some  very  nice  document  preparation  facilities  that 
produce  excellent  looking  documents  compared  to  what  you  would  get  doing  it 
with  a  typewriter. 


Respondent:  My  files  are  not  strictly  messages.  It’s  survey  reports,  inputs 
also  by  mail,  memos.  What  is  the  advantage  of  having  all  this  information  at 
hand  here  and  then  having  all  the  messages  in  another  area? 

Interviewer:  It’s  a  step  in  the  right  direction,  in  getting  all  that  information 
on-line  where  you  can  access  it  easily.  In  the  beginning  you  have  your 
messages. 

Respondent:  If  I  want  some  memos  from  J--  then  it  all  "goes  by  the  tubes." 

Interviewer:  We’ll  talk  about  memos  a  little  later  on,  because  perhaps  we  can 
offer  essentially  the  same  sort  of  facilities  for  intraoffice  memos  as  for  the 
DD-173.  But  large  documents  which  already  exist  won’t  be  there. 

Respondent:  When  I  open  a  folder,  I’ve  got  everything  I  want.  It’s  there. 
This  system,  to  me,  is  useless  because  it’s  not  there,  it’s  not  in  my  folder  in 
my  office.  I’ve  got  to  go  to  that  tube.  Right? 

Interviewer:  If  you  want  to  continue  operating  the  way  you  now  do,  then  you 
can  automatically  hardcopy  everything  that  comes  in  to  you,  and  file  it  away 
the  same  way  you  do  today.  That’s  one  option. 


Respondent:  What  if  you  normally  put  in  your  file  not  just  messages  but 
memos,  notes,  things  of  that  nature?  I  just  had  a  project  where  I  had  to  ask 
for  comment  from  not  only  external  agencies  where  messages  were  involved, 
but  internal  agencies  where  memos  were  involved.  And  perhaps  I  had  six 
responses  from  within  the  staff  and  three  messages  external.  Is  there  some 
way  that  I  could  enter  the  memos  into  the  file  in  addition  to  the  messages? 
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13.5  POINTING  DEVICES  VERSUS  FUNCTION  KEYS 


13.5.1  A  Question  on  Preferences  of  Input  Mode 

Pointing  devices  such  as  the  light  pen  were  described,  along  with  menu-like 
interaction.  Subjects  were  asked  if  they  preferred  this  style  of  inte-action  to  the 
keyboard/function  keys  that  we  had  been  working  with. 


13.5.2  Analysis  of  Responses  to  Input  Mode  Preferences 

Respondents  slightly  favored  keyboard/function  keys,  although  most  subjects  had  no 
strong  preference. 


13.5.3  Remarks  on  Input  Mode  Preferences 


Respondent:  Either  would  be  outstanding  compared  to  the  way  things  are 
done  now. 


Respondent:  I  would  prefer  to  push  the  buttons. 

13.6  INTERPRETATIONS  AND  RECOMMENDATIONS 

The  formal  message  is  but  one  of  many  communication  forms  used  by  J3  Operations. 
We  strongly  believe,  as  do  the  persons  we  interviewed,  that  the  utility  of  an  automated 
communications  system  is  directly  related  to  the  number  and  kinds  of  these  forms 
supported.  Therefore,  we  strongly  recommend  the  following  three  capabilities.  The  first 
is  formal  correspondence  within  CINCPAC  Headquarters.  A  minimum  useful  capability  is 
either  a  free  form  or  a  pro  forma,  where  all  formal  message  features  apply  with  respect 
to  filing,  alerting,  draft  review,  and  so  forth.  The  second  is  the  informal  free-form, 
stand-alone  note.  Since  this  is  informal,  there  should  be  a  guarantee  that  informal  notes 
are  never  archived.  Beyond  the  archive,  the  filing  and  alerting  and  other  mechanisms 
pertain.  The  third  is  the  direct  linking.  "Militarized"  syntax  and  vocabulary  for  the 
instructions  is  preferred,  yet  as  a  minimum,  we  would  endorse  the  TENEX  link  operations 
as  presently  implemented.  We  feel  that  offering  these  three  capabilities  will  greatly 
enhance  the  acceptance  and  usefulness  of  the  automated  service. 


14.  MILITARY -PROPOSED  FEATURES  AND  EXPRESSIONS  OF  CONCERN 


At  the  close  of  each  interview,  the  subject  was  asked  to  supply  any  additional 
remarks  that  he  or  she  felt  were  relevant  to  either  the  1977  test  service  or  to  a  later 
operational  service.  The  ensuing  dialogues  led  to  a  potpourri  of  needed  facilities  in  the 
context  of  both  the  experimental  service  and  an  operational  system.  In  this  chapter,  we 
highlight  some  of  those  features  most  germane  to  the  1977  test  service,  although  some  of 
them  apply  as  well  to  an  operational  environment.  Chapter  15  deals  exclusively  with  a 
future  operational  system. 

These  individuals  also  unveiled  many  potential  (with  respect  to  the  1977  iest 
service)  and  existing  (with  respect  to  LDMX)  problems  with  which  they  were  concerned. 
Some  of  the  dialogues  follow,  in  no  particular  order. 


14.1  LACK  OF  UNIQUENESS  OF  DATE-TIME  GROUP 


Respondent:  Someone  may  come  in  and  call  for  a  message  from  JCS  with  a 
date-time  group.  It  has  happened  in  the  past  that  we  have  had  two  or  three 
messages  from  XS  with  the  same  date-time  group. 

Interviewer:  The  DTG  and  PLA  of  originator  is  not  unique.  What  do  you  do  in 
a  case  like  this? 

Respondent:  We  send  them  a  copy  of  each  one  and  let  them  pick  out  the  one 
they  want.  ...  We  had  a  message  the  other  day  with  two  date-time  groups. 
The  one  at  the  top  and  the  one  and  the  bottom  were  different.  The  Admiral 
requested  it  by  the  top  one.  We  didn’t  have  it  filed  by  that  one  and  the 
comm  center  said  they  had  no  record  of  it.  We  finally  found  a  "bootleg"  copy 
and  discovered  the  problem. 

Interviewer:  In  the  service  we’re  talking  about,  it  is  generated  only  once  and 
then  electronically  copied  if  it  needs  to  appear  in  different  places.  So,  that 
won’t  happen. 


14.2  SATURATION  OF  EQUIPMENT 


Respondent:  We’re  only  getting  one  terminal  and  one  printer.  I’m  concerned 
with  having  people  stand  around  looking  over  my  shoulder  in  the  morning  to 
read  their  messages.  I  would  manipulate  the  buttons  and  they  would  stand 
around  and  read. 

Interviewer:  If  you’re  only  getting  one  terminal  for  the  office,  then  I  would 
suggest  that  you  get  hardcopies  for  your  bosses  and  let  them  work  in  the 
same  way  they  do  today.  Or  you  could  use  the  terminal  at  different  times. 


Respondent:  But  it  would  help  me. 
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143  SATURATION  WITH  RESPECT  TO  THE  COMMUNITY 


Respondent:  From  my  vantage  point,  for  it  to  receive  enthusiastic  acceptance, 
it  should  be  functioning  in  the  entire  Headquarters.  Because,  as  I  see  the 
biggest  advantage  of  the  system,  it  is  as  an  internal  coordinating  mechanism  in 
the  Headquarters.  And  it  would  be  most  desirable  for  me,  for  instance,  to  go 
to  J5  or  to  another  agency  outside  J3.  From  the  standpoint  of  time  and 
reaction  it  is  much  better. 

Interviewer:  In  an  operational  system,  of  course,  you  would  have  saturation. 
But,  unfortunately  for  this  test  next  year  that  won’t  be  the  case.  I  think  it  is 
mainly  a  question  of  dollars.  You  have  the  problem  of  not  reach;r  a 
threshold  of  use. 

Respondent:  I  understand  the  constraints  you’re  working  under.  You’re  going 
to  get  mixed  emotions  from  a  lot  of  people  because  they  can’t  do  their  work. 
You're  going  to  have  to  have  a  dual  capability  during  this  test.  No  question 
about  it.  We  work  a  lot  outside  our  immediate  area.  It  isn't  like  just  running 
around  Headquarters. 

Interviewer:  Perhaps  then,  where  you  can’t  reach  all  those  people,  its 
greatest  asset  will  be  the  personal  filing  operations. 


144  BANDWIDTH  AND  BAUD  RATE 


Respondent:  I  was  thinking  about  this  last  night.  I  thought  you  could  never 
perfect  something  where  I  can  go  through  a  stack  of  150  messages  as  fast  as 
I  can  now.  Now,  the  more  that  I  think  about  it,  since  I’ve  already  sorted  the 
immediates  and  flashes  ... 

Interviewer:  The  pigeonholing  and  categorizing  and  the  highlighting  we  spoke 
of  should  facilitate  that  somewhat.  However,  for  scanning,  paper  is  hard  to 
beat. 

Respondent:  I’m  concerned  about  the  display  rate.  I  scan  through  a  stack  of 
messages  and  pull  out  the  ones  I  want  to  keep.  Can  I  see  them  as  fast  as  I 
can  press  the  button? 

Interviewer:  One  thing  you  can  do  to  effectively  increase  the  baud  rate  is  to 
look  at  them  in  excerpt  form  so  that  you  are  only  extracting  the  information 
you  really  look  at  anyway.  So,  you  get  a  page  that  contains  that  information 
about  lots  of  messages  at  once.  When  you  press  the  button  to  page,  you  are 
looking  at  20  of  them  instead  of  one.  And  for  those  of  interest,  where  you 
want  to  see  the  entire  message,  then  you  have  a  different  button  to  display 
that  message.  But  we  won't  be  able  to  show  you  the  messages  in  their 
entirety  as  fast  as  you  flip  those  pages.  It’s  more  on  the  order  of  a  couple  of 
seconds. 


145  TYPING  SKILLS 


Respondent:  The  user  is  going  to  have  to  be  able  to  type  at  the  terminal. 

Interviewer:  Action  officers  or  their  aids  certainly  will  because  they  compose 
and  enter  text.  Those  people  receiving  messages  will  presumably  do  mostly 
button  pushing,  and  a  minimum  of  typing,  and  in  fact  would  not  be  a  typist.  It 
depends  upon  your  job  function.  Those  who  would  type  would  already  have 
been  trained  in  typing. 


146  SYSTEM  FAILURE  AND  BACKUP  ALTERNATIVES 


Respondent:  You’re  going  to  be  building  the  system  from  off-the-shelf 
components  and  we’re  going  to  be  working  with  it.  With  its  disablement, 
where  do  we  go,  and  how  do  we  get  hardcopy  of  data  we’ve  filed  in  the  files 
which  are  inoperable? 

Interviewer:  Presumably,  you’ll  have  in  parallel  the  system  you  now  have, 
LDMX. 

Respondent:  Is  that  a  good  presumption? 

Interviewer:  Yes.  At  least  during  the  extent  of  this  test. 

Respondent:  That’s  okay  as  long  as  I’m  assured  that  I  can  do  my  job  if  it 
"blows  a  fuse,"  if  a  cable  breaks,  or  a  subsystem  malfunctions. 

Interviewer:  Now.  That’s  true  of  the  formal  record  traffic.  However,  if  you 
put  a  lot  of  informal  correspondence  ... 

Respondent:  That  can  be  extremely  important  when  your  boss  is  wanting 
something. 

Interviewer:  Then  I  would  suggest  that  during  this  one-year  test,  you  also 
hardcopy  it. 

Respondent:  It’s  redundant,  and  a  very  expensive  proposition.  It’s  just 
something  I’m  bringing  up  and  something  we’ve  got  to  be  aware  of  and  should 
be  addressed. 

Interviewer:  The  point  is,  you  have  to  get  your  job  done  and,  at  the  same 
time,  there  is  a  need  to  test  the  service. 

147  OFFICE  CODES  AS  GLOBAL  PARAMETERS 


Respondent:  Names  change  and  codes  change.  This  happens  all  the  time  in  an 
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organization  this  large.  So,  I  guess  there  is  going  to  be  a  way  to  change 
everything  that  is  in  the  entire  system?  Let’s  say  they  change  J314  tomorrow 
to  be  J315.  And  everything  in  the  system  that  had  an  access  tor  314  will 
have  to  be  changed  to  315.  That  can  be  done? 

Interviewer:  That’s  something  we’ll  now  think  about.  No  one  has  raised  that 
issue  before.  How  often  does  that  occur? 

Respondent:  We  have  some  kind  of  organizational  change  once  every  month  or 
two  that  would  involve  this  kind  of  change.  And  of  course  you  have  people 
coming  and  going. 

Interviewer:  The  problem  of  people  coming  and  going  we’re  familiar  with.  We 
assume  that  generally  people  will  enter  office  codes  because  they  are  a  little 
more  permanent. 

Respondent:  I  would  think  so. 

14.8  LOCATING  THE  SUBJECT  LINE  OF  THE  MESSAGE 


Respondent:  The  subject  string.  Does  it  differentiate  between  that  and  the 
"pass  to"  lines?  Or  is  it  simply  the  first  line  after  the  classification? 

Interviewer:  I’m  not  sure  what  you  mean  by  "pass  to"  line. 

Respondent:  Back  here.  This  one  (Fig.  1-3).  That’s  the  classification  line. 
(That  ought  to  be  UNCLAS  instead  of  UNCLASSIFIED.)  And  then  you  have  a 
subject  as  the  next  line,  but  that  is  not  necessarily  true.  There  would  very 
frequently  be  a  pass  line  here  which  you  couldn’t  really  tell  from  a  subject 
line.  It  would  say  "Fifth  Air  Force  for  DOC,  PACFLT  for  DCOXK,"  and  so  on, 
things  like  that. 

Interviewer:  And  what  is  the  purpose  of  it? 

Respondent:  Mainly  in  the  Air  Force,  it  tells  the  comm  center  who  in  that 
command  should  get  the  message.  And  by  looking  at  that  you  would  have  no 
idea  what  the  subject  was.  This  could  run  as  many  as  three  or  four  lines. 

Interviewer:  Why  does  that  not  appear  in  the  distribution? 

Respondent:  Because  you  send  a  message  to  a  command.  And  if  you  know 
who  in  the  command  should  get  it,  then  you  put  that  in  your  "pass  to"  line. 


14.9  MESSAGE  READDRESbAlS 


Respondent:  What  about  getting  readdressals? 

Interviewer:  The  readdressal  is  a  separate  message.  You  would  receive  both 
the  readdressal  message  and  the  message  to  which  it  referred. 

Respondent:  On  this  page  (display  of  excerpts)  you  should  indicate  that  it  is  a 
readdressal.  Some  people  have  a  hard  time  with  this.  They  call  down 
wanting  a  message  but  they  give  us  the  date-time  group  of  the  readdressal 
message  instead  of  the  original  date-time. 

Interviewer:  We  could  perhaps  issue  both.  In  filling  out  a  readdressal,  since 
the  distribution  information  is  the  same,  the  service  could  automatically  fill  out 
most  of  it,  all  you  would  have  to  supply  would  be  the  PLA  of  the  new 
recipient. 


14.10  ADDRESSING  PRINTERS 


Respondent:  For  our  purposes,  we  want  everything  printed  on  our  printer. 
And  if  we  want  it  printed  somewhere  else,  we  say  that. 


14.11  TRAINING 


Respondent:  We’re  also  going  to  need  some  damn  good  instructors  to  come 
out  and  show  the  people  what  it  is  and  what  it  does. 


14.12  TERMINAL  USE  SEEN  AS  DEGRADING 


Respondent:  I  think  in  a  sense,  there  are  a  great  many  people  who  would  feel 
in  a  way  that  it  might  be  degrading  to  be  expected  to  sit  down  and  compose 
at  a  keyboard,  whereas,  they  have  no  compunction  about  using  a  piece  of 
wood  to  scratch  on  paper. 

Interviewer:  We  don't  look  at  it  as  making  everyone  a  clerk.  We  figure  you’d 
be  doing  the  same  functions  as  before  and  we’re  trying  to  give  you  more 
information  in  better  form,  and  more  timely.  Do  you  get  that  impression  or 
are  we  missing  the  mark? 

Respondent:  It  is  a  pretty  wide  mark.  I  think  that  ideally  a  lot  of  these  things 
have  to  be  brought  together.  There  is  a  tremendous  advance  being  made  in 
the  word  processing  area,  which  relieves  the  originator  of  both  writing  and 
typing  chores.  It  seems  to  expedite  the  flow  of  information.  The  clerks  seem 
to  accept  it.  And  I  think  the  final  product  is  something  better.  If  there  is 
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some  way  to  link  that  with  what  you  have  accomplished  here  in  automated 
message  handling,  I  think  that  would  be  ideal. 

Interviewer:  We  haven’t  talked  about  the  kinds  of  editing  facilities  that  can  be 
provided.  We  are  certainly  familiar  with  the  commercial  word  processing 
systems  and  much  of  that  will  be  incorporated  in  the  test  next  year,  along 
with  other  symbol  manipulation,  so  that  it  should  be  easier  for  the  guy 
entering  text  than  the  OCR  is  for  him  now. 


14.13  ERROR  PREVENTION 


Respondent:  There  ought  to  be  some  means  of  error  checking  of  messages  so 
that  if  you  have  a  secret  message  then  the  GDS  has  to  say  84.  That  is  a 
common  error.  There  are  a  lot  of  “busts"  on  that.  And  there  ought  to  be 
some  way  of  encouraging  people  to  use  ADS. 

Also,  there  ought  to  be  some  check  to  insure  that  you  have  no 
paragraph  that  is  classified  higher  than  the  classification  of  the  message.  And 
if  someone  changes  a  paragraph  along  the  line  that  changes  the  classification 
then  the  message  classification  has  to  change,  the  GDS  has  to  change.  I  think 
that  ought  to  be  automatic.  The  paragraph  marking  is  standardized. 


Respondent:  There  should  be  something  in  the  system  to  prevent  people  from 
deleting  files  by  accident.  You  should  have  to  type  out  DELETE  and  the 
system  should  come  back  and  ask  you  if  you  are  sure  you  want  to  do  this,  so 
that  you  have  to  go  through  two  or  three  steps  before  you  can  delete  a  file. 

Interviewer:  That  concept  should  extend  to  all  delete  operations  such  as  a 
message  or  a  draft. 


Respondent:  The  system  ought  to  make  sure  you  haven’t  misnumbered  the 
paragraphs.  Frequently,  people  leave  out  a  paragraph  or  paragraph  number. 

Interviewer:  What  are  the  consequences  of  doing  that? 

Respondent:  On  the  other  end,  you  don’t  know  if  you’ve  got  the  whole 
message.  Maybe  a  page  fell  on  the  floor. 


14.14  FIELD  INTERPRETATION 


Respondent:  The  thing  I  mentioned  earlier  in  the  citation  of  references,  I  really 
think  you  need  to  have  some  way  of  looking  at  the  command  title  and  then 
being  able  to  scan  past  other  information  and  then  come  up  with  the 


date-time  group.  Because,  lots  of  times  people  will  send  a  message  from,  for 
example,  CINCPACAF,  HICKAM,  AFB,  HI/DO  and  somebody  might  cite  that  simply 
as  CINCPACAF  DO  something  or  other.  So,  you  want  to  read  right  past  that 
until  you  get  to  the  numbers.  It  is  a  major  problem  with  LDMX  right  now. 
That  is  why  so  much  manual  intervention  has  to  take  place. 

Interviewer:  What  you  described  is  a  simple  enough  algorithm.  Is  that 
sufficient? 

Respondent:  Yes.  I  don’t  know  why  LDMX  doesn’t  do  that  now.  Unless  it  is 
letter  perfect,  like  it  appears  in  the  Message  Address  Directory,  then  the 
system  doesn’t  recognize  it. 


14.15  UPDATING  DISTRIBUTION  LISTS 


Respondent:  The  biggest  problem  is  to  get  people  to  look  at  them.  For 

example,  say  there  is  a  flagword  of - .  When  this  gets  reviewed,  if  it  is 

no  longer  valid,  no  one  will  delete  it  because  they  don’t  know  that  it  doesn’t 
belong  to  someone  else.  So,  you  really  need  to  be  able  to  have  an  owner  of 
each  individual  distribution  and  there  ought  to  be  a  means  for  him  to  get  a 
listing  of  everything  he  has  so  he  can  review  it  and  keep  it  up  to  date.  If 
you  do  that  then  people  will  maintain  them. 


14.16  AUTHORS’  COMMENT 

We  feel  that  the  issues  raised  in  sections  14.2,  14.3,  14.6,  14.7,  and  14.13  are 
particularly  important  with  regard  to  the  1977  test.  Although  we  generally  cited  a  single 
example  to  recognize  the  issue,  these  same  issues  were  identified  by  many  respondents. 


15.  MILITARY-PROPOSED  FEATURES  OF  AN  OPERATIONAL  SYSTEM 


Although  the  central  focus  of  the  study  reported  here  is  on  features  proposed  for 
the  test  service,  there  is  also,  obviously,  an  interest  in  features  beyond  the  purview  of  the 
test.  Some  such  features  are  mentioned  here  as  considerations  for  an  operational  system. 


15.1  EXTENDING  THE  SYSTEM  GEOGRAPHICALLY 


Respondent:  What  about  a  link  between  CINCPAC  and  the  JCS?  Is  that  in  the 
state  of  the  art? 

Interviewer:  It  is  certainly  in  the  state  of  the  art,  because,  for  example,  with 
the  ARPANET  [Roberts  70]  which  we  now  use,  we  have  connections  here  on 
the  Island  at  Camp  Smith,  throughout  the  Mainland,  and  also  in  European 
countries.  So,  our  present  system  is  sort  of  a  worldwide  network  and  is  used 
for  messages  and  other  functions.  It  is  not  suitable  for  your  use  because  of 
the  way  people  now  interface  with  it,  but  for  computer-trained  people  it  is 
effective.  We  would  envision,  for  an  operational  system  (not  this  test  next 
year)  that  it  certainly  ought  to  encompass  Washington  as  well  as  other 
locations.  I  would  think  it  would  be  a  part  of  the  AUTODIN  II  system  that  is 
being  planned.  The  technology  is  there.  Many  of  the  issues  will  be 
organizational,  methodological,  and  political. 


15.2  INTERFACING  TO  OTHER  SYSTEMS 


Respondent:  We’re  supposed  to  get  a  new  thing  called  MESDIS,  a  message 
distribution  system  for  data  pattern  messages,  to  go  right  into  our  computer 
files. 

Interviewer:  And  this  is  on  which  system? 

Respondent:  Honeywell  6000. 

Interviewer:  On  LDMX? 

Respondent:  Yes.  The  data  patterns  are  on  80-column  cards. 

Interviewer:  How  are  the  cards  generated? 

Respondent:  They  come  from  the  5th  Air  Force  or  SAC  Headquarters. 
Interviewer:  They  come  through  AUTODIN? 

Respondent:  Yes,  and  then  we  send  them  out  as  a  message  the  same  way. 
Interviewer:  Someone  here  also  punches  them  for  an  outgoing  message? 
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Respondent:  We  use  what  they  send  us  and  edit  it  --  update  it  in  our 
computer. 

Interviewer:  How  do  you  do  that? 

Respondent:  How  does  MOP  (Message  Output  Processor)  work? 

Interviewer:  How  do  you  indicate  that  you  want  to  update  such  a  message? 

Respondent:  I  run  an  update  after  I  receive  a  message.  With  MESDIS,  they 
really  don’t  have  the  capability  yet,  but  incoming  card  messages  will  go  onto 
my  file  and  I’ll  be  able  to  access  that  disk  file  and  run  an  update  and  access 
those  very  same  after-edited  transactions  and  send  them  on  the  JCS. 

Interviewer:  The  way  you  access  is  by  looking  at  card  images  on  a  CRT? 

Respondent:  Yes. 

Interviewer:  Many  such  facilities  are  possible,  including  typing  into  WWMCCS. 
But  that  kind  of  thing  won’t  be  available  in  this  test  next  year.  However,  if  it 
is  on  LDMX,  then  it  should  not  be  far  away  in  time  since  this  test  service 
couples  to  LDMX. 


Respondent:  Well  we  get  into  interfacing  problems,  but  these  are  things  now 
in  the  WWMCCS,  information  slides  and  things  of  that  kind  that  you  can 
produce  or  hardcopy.  It  would  be  nice  to  take  that  same  information  and 
distribute  it  to  the  subscribers  of  this  system.  Not  everyone  who  has  one  of 
these  terminals  will  be  on  WWMCCS. 

Interviewer:  With  later  AUTODIN  plans,  I  understand  they  may  be  tied 
together,  but  WWMCCS  will  not  be  tied  into  this  test  next  year,  in  any  way. 

Respondent:  I  can  see  real  utility  in  being  able  to  draft  information  using  our 
recon  information  system;  it’s  analogous  to  MOP.  MOP  is  an  existing  system 
we  now  use  in  reconnaissance  and  it  permits  us  to  create  card  images  on  the 
screen,  edit  them  and  then  transmit  them.  We  also  have  certain  recurring, 
relatively  stable,  formatted  messages  such  as  AIGs,  and  instead  of  sending  out 
a  message  saying  delete  this  guy,  add  this  guy,  our  practice  is  to  send  a 
recapitulation.  It’s  in  MOP  and  it’s  great.  You  don’t  have  to  worry  about  an 
E2  in  someone’s  comm  center  failing  to  update  the  AIG.  It  is  always  correct. 

Interviewer:  We  planned  something  like  that  that  I  didn’t  mention,  like  the 
AIGs,  where  you  can  build  lists  of  codes  and  store  them  away  with  a  name. 
Then  instead  of  typing  the  codes  into  a  message  every  time,  you  simply  type 
the  name  of  the  AIG  list  and  it  is  automatically  replaced  by  the  associated 
codes.  Would  that  be  useful? 

Respondent:  Oh,  yes.  That’s  nice  to  have.  The  AIG,  that’s  essential.  You’ve 
got  to  be  able  to  show,  on  request,  who  is  in  an  AIG.  These  are  in  the  LDMX 
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computer  right  now.  There  is  another  interface  problem.  We  are  also  able 
to  use  GOLDS  (General  On-Line  Display  System)  which  works  on  WWMCCS.  It 
permits  us  to  go  into  almost  any  data  base  and  pull  out  information  (one-time 
query  or  repeated  query)  and  build  a  product  which  is  a  particular  display. 
Then  we  can  transfer  that  to  MOP  and  send  it  as  a  message,  assuming  that  it 
is  not  more  that  80  characters  long.  Right  now  that  is  the  limitation. 
Frequently,  we  would  want  to  create  something  in  one  system  and  send  it  by 
message  to  others.  We  do  it  right  now  in  MOP.  So  "downstream"  you  need 
to  think  about  it. 


15.3  SECURITY  AND  SPECIAL  INTELLIGENCE  TRAFFIC 


Respondent:  Our  office  is  unique  in  that  we  go  through  more  messages  than 
anyone  else  in  J3.  But  our  overall  concern  is  SI. 


Respondent:  Take,  for  example,  the  command  center.  Everybody  is  SI  cleared, 
but  only  the  DDO  and  the  clerk  are  SI0P,  PSI  cleared.  If  you  have  a  setup  like 
this  you  have  to  be  sure  the  others  don’t  get  in. 

Interviewer:  Well,  the  state  of  the  art  doesn’t  allow  us  to  verify  and  certify 
the  code  in  the  computer.  We  can  do  it  in  very  simple  sorts  of  ways  —  very 
simple  algorithms,  but  not  in  a  general  way  such  as  with  an  operating  system. 
We  won’t  be  able  to  do  that  by  1985  either.  And  that  seems  to  be  a  major 
stumbling  block.  Although  there  are  pretty  good  safeguards  —  the 
probability  of  penetration  (deliberately  or  otherwise)  can  be  made  very  low 
as  a  function  of  cost. 


15.4  DOCUMENT  INPUT 


Respondent:  What  I’d  like  to  have  in  a  future  system  is  a  "look,  see,  print." 
When  I  feed  into  the  computer,  page-by-page,  rather  than  typing,  it  takes  the 
visual  imprint,  translates  that  and  reproduces  it  in  whatever  fashion.  I  Know 
the  state  of  the  art  is  there,  it  is  just  an  expensive  proposition. 

You  are  asking  questions  that  will  affect  the  overall  operation  of  an 
agency  such  as  J3. 


Respondent:  What  about  an  OCR  that  could  read  ordinary  documents? 

Interviewer:  To  my  knowledge,  there  are  no  plans  for  that  kind  of  facility  for 
this  test  in  1977.  Now,  for  a  follow-on  operational  system,  lots  of  people 
have  expressed  interest  in  getting  other  forms  of  documentation  on-line  and 
perhaps  that  will  be  a  consideration.  But  it  is  just  not  in  the  plans  for  this 
test.  But,  hopefully,  you’ll  be  able  to  do  the  intraoffice  correspondence. 


16.  CONCLUSIONS 


16.1  A  RECAPITULATION  OF  DESIRABLE  FEATURES 

Below,  in  summary,  we  tabulate  only  numerically  rated  features  and  only  those  that 
received  a  mean  of  1.0  (desirable)  or  higher.  The  most  frequently  occurring  response  (the 
mode)  is  also  given.  Remember,  though,  that  many  nonnumerically  rated  features  are 
required. 


Feature 

Mean 

Mode 

Point  Paper 

2.6 

3 

Programming  Events 

2.5 

3 

Automatic  Archival 

2.4 

3 

General  File  Organization 

2.3 

3 

Message  Retrieval  Specifications 

2.2 

2 

Message  Access  Based  on  Two  Conditions 

2.1 

2 

File  Access  Privileges 

2.0 

3 

Automatic  Filing 

2.0 

2 

Maintaining  Single  Draft  Version 

2.0 

1-3 

Commenting  File  Entries 

1.9 

2 

Exempting  Messages  from  Archive 

1.9 

1 

Message  Access  by  Logical  Expressions 

1.8 

3 

Commenting  the  Draft  Message 

1.8 

3 

Formatting  Message  Excerpts 

1.7 

3 

Terminal  Linking  Facility 

1.7 

2 

Programming  Notice 

1.6 

2 

Commenting  the  Released  Message 

1.6 

2 

Field-Specific  Draft  Comments 

1.5 

3 

Formal  Nonmessage  Communications 

1.5 

2 

Informal  Message  Service 

1.4 

1 

Programmed  File  Instructions 

1.3 

0-2 

Explicit  Archival 

1.2 

1-2 

File  Header  Comments 

1.2 

1 

Those  numerically  rated  or  numerically  analyzed  features  that  were  not  desirable 
included  the  reordering  of  message  fields,  the  suppression  of  message  fields,  defining 
excerpts  differently  for  different  files,  and  the  application  of  comments  to  specific  fields  of 
received  messages. 


16.2  A  CHARACTERIZATION  OF  ESSENTIAL  CAPABILITIES 

Throughout  the  report  we  have  given  recommendations  for  minimum  and  also 
elaborate  capabilities.  Below,  we  characterize  the  service  by  listing  (in  a  general  way) 
some  major  minimal  capabilities.  This  is  included  for  the  reader  who  is  not  interested  nor 
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has  the  need  for  the  details.  It  in  no  to  ay  supplants  our  earlier  recommendations  at  the 
end  of  most  chapters. 

1.  The  ability  to  input  the  text  of  a  message  and  send  it  to  others  for  their  approval, 
editing,  or  comments. 

2.  An  input  file  such  as  the  pending  file  to  automatically  catch  all  incoming  traffic. 

3.  The  ability  to  explicitly  file  items  in  subject  files  that  are  defined  by  the  user. 

4.  The  ability  to  recall  items  or  their  excerpts  by  logical  expressions  of  originator,  DTG 
range,  and  user-specified  keywords  supplied  by  him  when  filing. 

5.  Notification  that  a  new  message  has  arrived  in  the  input  file. 

6.  An  automatic  archive  facility. 

7.  The  application  of  the  above  to  informal  notes  (excepting  archive)  and  to  free-form 
formal  correspondence  within  the  Headquarters.  The  interactive  terminal-to-terminal 
capability  is  also  needed. 


16.3  THE  RESPONDENTS’  GENERAL  ATTITUDES  TOWARD  THE  SERVICE 

Would  such  a  service  as  proposed  herein  be  well  received,  given  proper  training 
conditions  and  reliable  equipment?  The  answer  is  yes,  emphatically.  In  terms  of  their 
overall  attitudes  toward  the  service  we  described,  we  can  divide  the  respondents  into 
three  groups.  Two  of  the  24  were  very  pessimistic.  Basically,  these  two  gentlemen  did 
not  believe  a  service  as  described  would  be  useful  to  them.  Their  ratings  generally 
ranged  from  0  to  -3.  To  insure  representation  of  all  attitudes,  their  remarks  appear 
throughout  the  report,  perhaps  out  of  proportion  to  their  number.  A  second  group  of 
about  6  or  8  of  the  24  were  highly  optimistic.  They  liked  everything  about  the  proposed 
service  and  felt  that  it  would  help  them  in  their  job,  perhaps  more  than  it  actually  would. 
The  remainder,  the  largest  of  these  three  groups,  was  generally  skeptical  initially.  But 
throughout  the  course  of  the  interview,  they  discovered  parts  of  the  service  which  they 
believed  could  greatly  facilitate  their  operations.  The  members  of  this  group  made  many 
useful  contributions  to  our  understanding  of  their  needs  and  to  our  understanding  of  the 
limitations  to  which  the  test  service  would  apply. 

Perhaps  the  most  common  unsolicited  responses  from  most  of  the  subjects  identified 
three  needs.  One  need  is  to  cover  their  functional  needs  which  extend  beyond  formal 
record  traffic  between  distant  points.  Another  need  is  to  be  able  to  reach  those  persons, 
beyond  J3  personnel,  with  whom  they  work  daily.  And  lastly,  they  need  a  familar, 
English-like  language  for  the  man-computer  interaction.  We  agree. 
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